منو
  • مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
  • بهینه سازی موتورهای جستجو محمد زند

مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی

مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی

مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
تصویر ياسر سليماني
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط ياسر سليماني - شنبه، 18 بهمن 1393، 01:23 ب.ظ
  يكي از پروژه هاي شكست خوده محصول جديد شرکت RIM بنام Blackberry Torch هست كه در رقابت بازار گوشی‌های همراه هوشمند، موبایلی با صفحه نمایش لمسی عرضه کرد این گوشی دارای سیستم عاملی جدید است که قابلیت‌های بسیار بالاتری نسبت به نسخه‌های قدیمی سیستم عامل بلک‌بری دارد.
این گوشی مانند تمام گوشی‌های هوشمند دیگر برپایه شبکه‌های اجتماعی توسعه یافته و نرم‌افزارهای کار با شبکه‌های اجتماعی معروف برروی آن از پیش نصب شده‌اند.
تحلیل‌گران معتقدند مرورگرهای وب گوشی‌های بلک‌بری نقطه قوت این گوشی‌ها هستند و اکنون نیز اين گوشی جدید به HTML5 مجهز شده است.
هدف پروژه:
بلک‌بری تلاش کرد با تولید و عرضه Torch به رقابت با آندروئید و آی.فون بازگردد و بخشی از بازار از دست‌رفته را دوباره به دست بگیرد. اما این نمونه تازه نیز سهم چندانی از بازار پرهیاهوی تلفن‌های هوشمند نداشت.
به نظر من اشتباه شرکت در همین بخش بود؛ زمانی که اعلام کردند BB 10 روی تلفن‌های همراه نسل گذشته بلک‌بری کار نمی‌کند. در واقع این پیام نهفته که «اگر BB 10 رو دوست داری باید یه گوشی جدید بخری» حسابی به ضرر آن‌ها عمل کرد. البته در کنار بلک بری، مایکروسافت هم چنین اشتباهی را در مورد ویندوز فون 8 مرتکب شد، اما تفاوت ماجرا در این بود که نخست بلک‌بری طرفداران خاص خودش را داشت که البته با این حرکت بسیاری از آن‌ها را از دست داد و در وهله دوم برعکس مایکروسافت، آن‌ها خودشان مسئولیت ساخت هر دو بخش نرم‌افزار و سخت‌افزار را برعهده داشتد.
تعريف شكست
شکست در پروژه‌های نرم‌افزاری در هر یک از چهار مورد «هزینه»، «زمان»، «کیفیت» و «دست‌یابی به اهداف» مطرح می‌گردد؛ بدین معنا که اگر پروژه‌ای با صرف هزینه‌ی بیشتر یا زمان بیشتر یا با کیفیت پایین‌تر انجام گردد، علی‌رغم به پایان رسیدن پروژه، آن را توأم با شکست می‌دانیم.
علل اصلی شکست پروژه‌ Blackberry Torch

• ضعف ورودی کاربر
• نیازمندی‌های مبهم
• تخمین دور از واقعیت برای هزینه و زمان
• هزینه‌های پنهان
• شکست طراحی
• طبقه‌بندی ارتباطات
• معماری ضعیف


تصویر ندا نجفي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط ندا نجفي - شنبه، 18 بهمن 1393، 11:41 ب.ظ
 

نام پروژه :promise

نوع محصول : سيستم مديريت فروش و سفارشات

محصول كشور كانادا

تاريخ : دسامبر 2013


شركت آون در ابتدا براي فروش محصولات خود كارمندان فروشش را مستقيم به خانه هاي افراد ميفرستاد تا از اين طريق محصولات شركت را به انان عرضه كنند.

بر اساس گزارشات تعداد قابل توجهي از تيم فروش آون در كانادا ديگر نميخواستند با مراجعه به درب منزل مشتريان اقدام به فروش محصولات كنند.

آون با استفاده از استراتژي بازاريابي multi – level و استفاده از يكي از شركتهاي فروش مستقيم در جهان اقدام به توزيع محصولات خود كرد؛از طريق شبكه اي از عوامل فروش (كه به فروش مستقيم به خانواده ، دوست و آشنايان ميپرداختند).در چنين كسب و كاري عوامل فروش يك لينك مهم در زنجيره هستند اگر آنها اعتمادشان را به شما ازدست دهند سپس آن كانال توزيع شما از بين ميرود.متاسفانه گزارش ها نشان ميدهد كه آون آن اطميناني كه تيم فروش كانادايي اش به آن داشتند با معرفي سيستم جديد مديريت فروش و سفارشاتش ،از دست داد.

سيستم جديد به عنوان قسمتي از پروژه جهاني SMT(Service Model Transformaition ) معرفي شد .سيستم جديد براي ساده كردن فرآيند سفارش در نظر گرفته شده بود تا بدين طريق باعث كاهش هزينه و رفع بهتر نيازها و انتظارات مشتري شود.(هدف پروژه)

آون از يك سيستم جديد ERP (back-end) استفاده كرد .سيستم SMT در نظر گرفته شده بود تا به عوامل فروش اجازه دهد با استفاده از تبلت هاي خود محصولات را به نمايش بگذارند و با گرفتن سفارشات بتوانند بصورت آنلاين موجودي را چك كنند.

پروژه Promise در آغاز به منظور صرفه جويي بطور تقريبي 40 M$ در هر سال با بكارگيري SMT در نظر گرفته شده بود.

يك پرونده اي در كميسيون بورس و اوراق بهادار (SEC) تشكيل شد و با توجه به آن پروژه آون در 9 دسامبر 2013 با هزينه بين 100$ تا 125M$ رها شده بود .(نتيجه پروژه)

طبق اين پرونده ، اين سيستم با اينكه به عنوان يك راهنمايي قوي در كانادا تبديل شده بود اما اختلال قابل توجهي در كسب و كار آن بازار ايجاد كرده بود.پر كردن برگه هاي (SEC)نشان ميداد كه اين سيستم بازگشت سرمايه را بطور شفاف نشان نميدهد و تصميم براي توقف پروژه گرفته شد به دليل اينكه احتمال دارد اختلال بيشتري در كسب و كار ايجاد كند.

گزارش هاي موجود در مطبوعات نشان ميدهد كه توابع عمومي مانند ورود به سيستم ، صرفه جويي در سفارشات ، چك كردن موجودي به درستي كار نميكند.؛ علاوه بر اينها شكايت هايي در مورد قابليت استفاده نيز منتشر شده است .

كاربران تبلت ها عادت كرده بودند كه با لمس انگشت و جهت يابي به آساني از برنامه ها استفاده كنند . گزارش ها نشان ميدهد كه رابط كاربر آون ساختار ضعيفي داشت و انتظارات كاربران را از يك برنامه كاربردي مخصوص تبلت براورده نميكند؛ در حالي كه سيستم هاي (back – end) ايجاد ميشوند براي اينكه كارها را ساده تر كنند . در برنامه هاي كاربردي گذشته مراحل به اينگونه بود تايپ كردن ،انتخاب ليست ها ،پركردن اشكال و مراحل متعدد؛ اما در برنامه هاي كاربردي امروزي اين كار از ابتدا تا انتها طي چند مرحله كوچك كه در هر مرحله از گرافيك و تصاوير و آيكون هايي براي ساده سازي استفاده ميشود انجام ميشود.

اين مشكل تاثير بسيار زيادي گذاشت بطوري كه يكي از مديران ارشد فروش گزارش داد كه او بيش از 300 ازعوامل فروش خود را از دست داده است .(1/3 از كل تيم فروش خود )

درسهاي گرفته شده ازپروژه:

1- پروژه ها را بايد ابتدا در بازارهاي كوچك مورد آزمايش قرار داد قبل از رفتن به بازارهاي بزرگ و جهاني ، تا مشكلات و معايب آنها مشخص شود .

2- عوامل موثر در شكست اين پروژه عبارتند از :

· نقص كيفيت

· عدم تجزيه و تحليل درست ذينفعان و مشخص كردن نيازمندي هاي آنان

· عدم درك انتظارات عوامل فروش از برنامه

 

تصویر پوران ساجدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط پوران ساجدي - يکشنبه، 19 بهمن 1393، 12:44 ب.ظ
 

جالب است که بدانیم چرا هیچوقت شکست یک پروژه در ایران اعلام نمی شود و یا اینکه پروژه های شکست خورده همچنان ادامه حیات می دهند؟ یعنی اگر هم برای همه واضح باشد که یک پروژه شکست خورده است باز هم مسئول مربوطه مصاحبه می کند و امیدواری می دهد که آن پروژه به زودی به اتمام خواهد رسید نمونه هایش فراوان است ولی موضوع بحث ما صرفا شکست های نرم افزاری و IT است. البته تعداد شکست های اینگونه در ایران به دلیل فقر نرم افزاری، سخت افزاری و انفورماتیک کشور کم است ولی این امر دلیل نمی شود تا از آنها نامی به میان نیاید. با هم تعدادی از آنها را مرور می کنیم:

 

1. تولید گوشی ایرانی

"کارخانجات مخابراتی ایران (ITMC) که پیش از این در پروژه تولید گوشی ملی فعالیت داشت با شرکت خودروسازی ایران خودرو برای تولید خودرو در کشور مشارکت می‌کند."

این تنها یک نمونه از این شکست است. شاید یا خود بگویید پس این GLX که این همه تبلیغ می کند چیست؟ خول شاید GLX ایرانی باشد (البته حتی اسم اش هم ایرانی نیست چه برسد به...) اما واقعا هدف این پروژه پر سر و صدا رسیدن به تولید GLX آن هم بعد از 5 سال بود؟

اوایل کار چندان بد پیش نمی رفت: تولید LG در مادیران، تولید Hyundai در نیمه هادی عماد، تولید گوشی با برند ITMC در ITMC، تولید همین GLX خودمون که تابلو بود از چین وارد میشه, …

مادیران فقط به اسمبل بخش‌های اصلی گوشی می‌پرداخت و تنها 5 مدل از گوشی‌هایی که پیش تر توسط نماینده قانونی ال جی به بازار راه یافته بود را مونتاژ می‌کرد. هرچند که مادیران گوشی‌های تولیدی خود را اندکی ارزان تر از نمونه مشابه خارجی خود به بازار معرفی کرد اما این بار با قیمت شکنی از سوی نماینده رسمی ال جی یعنی پرشین تله کام روبر شد و باعث شد تا استقبال مناسبی از اولین گوشی‌های به ظاهر ساخت ایران صورت نگیرد.

بعد از ال جی، GLXگوشی‌ای ‌بود که در یک سکوت خبری روانه بازار شد. GLXهم به دلیل بالا بودن قیمت تمام شده برای کارخانه نتوانست سهمی از بازار را به خود اختصاص دهد.

سپس نوبت به کارخانجات مخابراتی ایران رسید. کارخانه‌ای که پیشتر نیز با شریک آلمانی خود یعنی زیمنس به تولید گوشی‌های ثابت تلفن همراه می‌پرداخت، این بار بازار تلفن همراه را نشانه گرفته بود و با یک کار تحقیقاتی جامع خط تولید گوشی ‌های خود را افتتاح کرد و عنوان داشت که به زودی و طی یک سال، 2 میلیون گوشی ایرانی با برند ITMCرا روانه بازار خواهد کرد. در ابتدای این مطلب خواندید که چه بلایی سر ITMC آمد!

به راستی چند نفر از ما و اطرافیانمان گوشی ایرانی داریم؟ به هر حال به نظر من با دستور و بخشنامه نمی توان محصولات نرم افزاری و سخت افزاری را "ملی" کرد. وقتی هنوز دانش فنی ساختش را نداریم چرا باید روی تولیدش اصرار داشته باشیم؟

 

تصویر پوران ساجدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط پوران ساجدي - يکشنبه، 19 بهمن 1393، 12:38 ب.ظ
 

2. لینوکس فارسی:

به این خبر از سال 385 توجه کنید:

"در سال 84 تعداد بسياري كتاب فارسي در زمينه وب سرور ، تعامل ويندوز و لينوكس و مهاجرت به لينوكس توسط مركز ICT پيشرفته شريف با همكاري شوراهاي عالي اطلاع‌‏رساني انفورماتيك به سازمان‌‏ها و ارگان‌‏ها فرستاده شد.

به گزارش بخش خبر شبكه فن آوري اطلاعات ايران، از ایلنا، مهندس جلال حاجي غلامعلي ، مشاور ارشد طرح ملي لينوكس فارسي ، با بيان اين مطلب، اظهار داشت: سال گذشته با برپايي سمينارها و جلساتي در خصوص سيستم عامل ملي تعدادي از سازمان‌‏ها به لينوكس مهاجرت پيدا كردند

وي ، گفت: در حال حاضر چند بانك دولتي و خصوصي ، شركت‌‏هاي بيمه و چند سازمان دولتي از لينوكس فارسي به عنوان سيستم عامل استفاده مي‌‏كنند.

مشاور ارشد طرح ملي لينوكس فارسي ، از ديگر فعاليت‌‏هاي مركز ICT پيشرفته شريف به عنوان بنيان‌‏گذار لينوكس فارسي به چاپ كتاب‌‏هايي چون سيستم عامل متن باز و دولت‌‏ها ، كسب و كار با سيستم عامل متن باز و وب سرويس آپاچي اشاره كرد و افزود: اين مركز هر ماه يك نشريه در خصوص سيستم عامل آزاد- متن باز ارايه مي‌‏دهد.

مهندس حاجي غلامعلي ، با اشاره به برگزار سمينارهاي مختلف در دانشگاه‌‏ها ، يادآور شد: براي فرهنگ‌‏سازي لينوكس فارسي به آموزش اين نرم‌‏افزار در دانشگاه‌‏هاي مختلف و تعدادي از سازمان‌‏ها پرداختم.

وي ، با بيان اين كه دولت به اندازه كافي بودجه در اختيار اين طرح قرار نداده است ، افزود: طي هفته گذشته دو كتاب مهاجرت به لينوكس و بانك اطلاعاتي پست گره توسط مركز ICTپيشرفته شريف ترجمه و به شوراي عالي اطلاع‌‏رساني و انفورماتيك ارايه شد.

مهندس حاجي غلامعلي ، با اظهار اميدواري از اين كه سازمان‌‏ها و ارگان‌‏هاي دولتي از اين اپن‌ ‏سورس استفاده كنند ، در خصوص تركيب جديد شوراي عالي اطلاع‌‏رساني ، گفت: اميدواريم امسال با اين تركيب جديد پروژه ملي لينوكس فارسي را به اتمام برسانيم.

مشاور ارشد طرح ملي لينوكس فارسي ، خاطرنشان كرد: هر پروژه‌‏اي داراي ابتدا و انتها است و پروژه لينوكس فارسي نيز در انتهاي راه قرار دارد كه اميد مي‌‏رود پايان امسال اين پروژه به اتمام برسد.

وي ، پشتيباني سازمان‌‏ها از اين طرح را بسيار موثر ارزيابي و تاكيد كرد: كمبود اعتبارات اختصاص داده شده و عدم اختصاص بودجه مصوب شده باعث شد كه پروژه ملي لينوكس فارسي تا حدي به تعويق بيافتد. "

من نمیدانم واقعا این پروژه لینوکس فارسی به اتمام رسید یا نه فقط این را می دانم پروژه ای که "ملی" خطاب می شود یعنی باید فراگیر باشد. .ویژن طراحان و مدیران این پروژه این بود که تمام رایانه های سازمانها و ارگانهای دولتی ابران ظرف مدت کوتاهی با لینوکس فارسی کار کنند و به این ترتیب کشور از وابستگی به بیگانه رها شود. در واقع علت اصلی اجرای این طرح نگرانی بابت اجرای کپی رایت در ایران بود. جرا که با پیوستن ایران به سازمان تجارت جهانی اجرای کپی رایت در ایران الزامی می شد و این هزینه بسیاری را بر دولت تحمیل میکرد. شاید فکر اولیه برای انجام چنین پروژه ای خوب بود اما اجرای و نتیجه اش اصلا مطابق انتظار نبوده است.

تصویر كيومرث رمضاني
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط كيومرث رمضاني - دوشنبه، 20 بهمن 1393، 11:48 ق.ظ
  بررسي موانع و مشکلات پياده‌سازی سيستم‌هاي اطلاعات مديريت (MIS) در كشور


در اين مقاله به بررسي مشكلات و موانع پيش روي سازمان‌ها در استقرار و پیاده‌سازی سيستم‌هاي اطلاعات مديريت (MIS)در كشور پرداخته‌ شده است. چرا كه استفاده سنجيده و آگاهانه از فناوري هاي اطلاعاتي مدرن به ويژه MIS در كشور مي‌تواند راه توسعه، پيشرفت و ترقي كشور را هموارتر سازد.
در عصر حاضر، مديران نياز پيدا كرده اند كه اطلاعات مربوط به اموري را كه با آن سروكار دارند بشناسند، گردآوري و تحليل كنند، سازمان بدهند و با مراعات سه عامل مهم سرعت، دقت و هزينه آنرا مبادله كنند.
اطلاعات درون هر سيستم در هر لحظه از زمان دانش و آگاهي آن سيستم را تشكيل مي‌دهد. اين دانش به طور تدريجي و در طول زمان از طريق جذب پاره هاي مختلف داده و تبديل آن به اطلاعات پديد آمده است. 
رمز موفقيت هر مدير و نظام مديريت در هر سازمان اين است كه بتواند گام به گام داده هاي جديد را با دانش پيشين سازمان پيوند دهد و مقدمات دريافت و آماده سازي اطلاعات نوين را فراهم آورد. بكوشد تا به فراخور وضع سازمان و با توجه به مراتب مختلف زيرمجموعه آن سازمان، توان دريافت اطلاعات جديد را در سازمان بالا ببرد. 
فقر و ضعف اطلاعات موجب مي‌شود كه مديريت سازمان نه تنها تصوير درست و كاملي از آينده نداشته باشد، بلكه حتي نتواند نقاط قوت وضعف وضع گذشته و موجود سازمان را درست و كامل بشناسد. در نتيجه نه مي‌تواند هدف گذاري صحيح انجام دهد و نه قادر است فعاليت‌هاي مناسبي را براي سازمان طراحي نمايد و پيرو اين امر از منابع سازمان استفاده بهينه نخواهد كرد.
لذا مي‌توان يكي از عمده ترين دلايل عدم كارآيي و عدم موفقيت سازمان‌ها را تصميم گيري ضعيف مديريت سازمان به علت عدم وجود اطلاعات كافي و مناسب دانست و اين مي‌تواند به دليل اهميت كافي قايل نشدن براي اطلاعات، تأمين نكردن زيربناهاي مناسب، و ضعف در توليد، سازماندهي، ذخيره سازي و اشاعه اطلاعات مناسب، دقيق، صحيح، قابل اعتماد، به هنگام و كامل باشد.
در هر سازمان، مي‌بايد داده‌هاي متنوعي را از درون و بيرون سازمان گردآوري و از طريق مجاري ارتباطي و ارتباطات مناسب به سيستمي كه پردازش اطلاعات را انجام مي‌دهد، منتقل نمود. پردازش اطلاعات نيز بايستي به گونه‌اي باشد كه سيستم بتواند اطلاعات ضروري، به هنگام و در عين حال كافي و مناسب براي تصميم گيري را توليد و به تصميم گيرندگان ارايه نمايد. چرا كه از يك طرف داشتن ‌‌‌اطلاعات اضافي و غير ضرور، صرف نظر از اتلاف وقت و هدر دادن منابع، خطر درگير شدن مديران با انبوهي از اطلاعات مربوط به جزييات غير لازم را پيش مي آورد و سردرگمي وي را، به دنبال دارد. 
مديريت امروز در مواجهه با افزايش حجم و پيچيدگي تصميم گيري‌ها دريافته است كه سيستم‌هاي دستي گسترده، پراكنده و در برخي موارد غير مرتبط موجود، با توجه به اهميتي كه براي اطلاعات در فوق بر شمرده شد، قادر به تامين اطلاعات مورد نياز و ارايه آنها در زمان مناسب، نمي‌باشند. اغلب مديران با انبوهي از داده‌ها و يا طوماري از سوابق اطلاعاتي روبرو هستند كه تاثير چنداني براي آنها در تصميم گيري، برنامه ريزي، سازمان دهي و كنترل و هدايت صحيح و مطلوب در سازمان ندارد.
شكاف بين سيستم‌هاي اطلاعاتي ثابت و محيط و ساختارهاي سازماني متغير به ويژه در سازمان‌هاي پويا، نيز مشكل بنيادي ديگري است كه موجبات ضعف اطلاعاتي را فراهم مي سازد زيرا هر تغييري در ساختار سازمان، تغييراتي را در مشاغل، مسووليت ها، حيطه اختيارات، سلسله مراتب مديريت و... به وجود مي آورد و اين تغييرات به نوبه خود موجب بروز نيازهاي اطلاعاتي جديدي مي‌شود كه به طور معمول سيستم‌هاي ثابت اطلاعاتي موجود فاقد اين اطلاعات جديد هستند و مي‌بايستي تغييرات لازم در آنها ايجاد گردد.
سيستم اطلاعات مديريت، سامانه سازمان يافته و ابزار مناسبي است كه اطلاعات به هنگام، صحيح و خلاصه شده را در موقع مناسب به تصميم گيرندگان سازمان ارايه داده و امكان تصميم گيري صحيح و دقيق را براي مديران سازمان فراهم مي سازد. هدف نهايي از ايجاد سيستم ها گردآوري، پالايش، تجزيه و تحليل، پردازش، فشرده و تلخيص كردن، ذخيره كردن و سرانجام انتقال تمامي اطلاعات گذشته و حال سازمان‌ها و پديده هاي مرتبط با آنها، در يك بانك اطلاعاتي متمركز با امكان دسترسي سريع براي مديران آنها است. 
سيستم‌هاي اطلاعاتي مديريت موجبات افزايش آگاهي هاي مديران و حتي كارشناسان سطوح مختلف سازمان را فراهم ساخته، با طرح مفاهيم جديد نه تنها حيطه دانش آنها را در مورد اينكه قادر به انجام چه كارهايي و اتخاذ چه تصميم هايي خواهند بود وسعت مي بخشد، بلكه آنان را درهرچه بهتر انجام دادن مسووليتها و فعاليت‌هايشان ياري مي نمايد.
براي سيستم‌هاي اطلاعاتي تعاريف مختلفي ارايه گرديده است. در اكثر اين تعاريف سيستم‌هاي اطلاعاتي را مجموعه اي از؛ افراد (كاربران، راهبران، طراحان)، داده‌ها، روش‌ها، نرم افزارها، سخت افزارها و ابزارها . . . مي دانند.
بر اساس این تعريف افراد و به تعبيري انسان ركن اصلي و اساسي در سيستم‌هاي اطلاعاتي محسوب مي‌گردد. در صورتي كه اين عامل اصلي، نقش و وظيفه خود را به خوبي ايفا ننمايد، به طور قطع در كارآيي و بهره‌وري سيستم‌هاي اطلاعاتي بايد شك نمود. به اين لحاظ و به دليل اهميتي كه اين عامل در هر يك از مراحل فرايند ايجاد و بكارگيري سيستم‌هاي اطلاعاتي دارد (يعني مراحل مطالعات امكان پذيري، برنامه ريزي، تجزيه و تحليل نيازها، طراحي، برنامه نويسي و ساخت، استقرار و پياده سازي و نگهداري و توسعه، بررسي پيرامون اين موضوع به ويژه در كشور ما مفيد فايده به نظر مي‌رسد.
در فرايند طراحي، پياده سازي و بكارگيري سيستم‌هاي اطلاعات مديريت به طور معمول سه گروه از انسانها شامل:

(1) بكارگيرندگان اصلی سيستم كه همان مديران مي‌باشند،
(2) طراحان يا برپاكنندگان سيستم (كه همان طراحان، برنامه نويسان و سازندگان سيستم مي‌باشند(،
(3) راهبران (كه همان متصديان و دست اندركاران ارسال، گردآوري، آماده سازي و تغذيه اطلاعات به سيستم و اپراتورها و متصديان و مديران عمليات راهبري، ارايه خدمات اطلاعاتي و نگهداري سيستم مي‌باشند(،
نقش اساسي را ايفاد مي نمايند و علاوه بر آنكه ويژگي ها و خصوصيات فردي هريك از اين سه دسته در افزايش بهره دهي سيستم مؤثر است.
سيستم‌هاي اطلاعاتي در سازمان ها، موجبات تسهيل در بكارگيري بهينه دو عامل اساسي يعني انسان و اطلاعات را در سازمان فراهم مي آورند. ضمن آنكه از ساير عواملي كه در سازمان ها مورد استفاده قرار مي گيرند، يعني مواد اوليه، پول، خدمات، انرژي، ماشين آلات، تجهيزات، ابزار، ساختمان و ... نيز به طور بهينه بهره گيري مي‌شود. 
عمده دلايلي كه موجب مي‌گردد مديران در سازمان‌ها رو به سيستم‌هاي اطلاعات مديريت آورده و به آن نياز پيدا نمايند عبارتند از:
(1) بروز پديده انفجار اطلاعات و عدم تأمين اطلاعات مناسب و مورد نياز براي تصميم گيري
(2) محيط متحول و متغير سازمان‌ها و رشد سريع تغييرات
(3) افزايش پيچيدگي مديريت 
(4) استقلال واحدهاي مختلف سازماني
(5) بهبود و افزايش بهره‌وري (كارآيي و اثربخشي) فعاليت‌هاي سازمان
(6) بروز پديده قدرت اطلاعاتي در كاركنان و مديران سطوح پايين تر در سازمان
(7) مشغله زياد مديران و كمبود وقت
(8) وجود ارتباطات نامناسب در سازمان
(9) عدم وجود نظام هاي كنترلي مناسب در سازمان
(10) ضرورت افزايش سرعت در تصميم گيري ها
(11) كمبود منابع مالي و كاهش هزينه ها
MIS دو نقش اساسي را در تصميم گيري مديران بازي مي كند. اول آنكه به مديران كمك مي كند تا بر اساس اطلاعاتي كه آماده نموده و در اختيار آنان قرار مي‌دهد، تصميم گيري نمايند. دوم آنكه در شرايطي كه الگوي تصميم گيري و تصميمات ثابت مي‌مانند و فقط داده‌هاي ورودي آن تغيير مي نمايد، به عنوان تكرار كننده مناسب جهت پشتيباني انواع تصميمات مديران خواهد بود. يعني MIS ابزاري است كه به عنوان يك منبع اطلاعات سازماني، اطلاعات مورد نياز مديران را آماده نموده و براي تصميم گيري آنها مهيا مي‌نمايد. 
برخي ويژگي‌هايي را كه مي‌توان براي سيستم‌هاي اطلاعات مديريت خوب و مناسب برشمرد عبارتند از:
• اطلاعات را با ويژگي‌هاي مناسب از نظر محتوي، زمان و شكل براي مدير فراهم آورد.
• اهداف و نيازهاي اطلاعاتي مدير را به طور كامل پاسخگو باشد و بتواند در حل مسايل و تصميم‌گيري، وي را ياري نمايد.
• قابليت توسعه و بهبود در آينده را داشته باشد چرا كه نيازهاي اطلاعاتي مديران در طول زمان تغيير مي نمايد.
• مورد پذيرش و قبول كاركنان (راهبران) و كاربران آن قرار گيرد و جنبه هاي انساني در آن خوب لحاظ شود.
• هزينه طراحي، استقرار، بهره برداري ونگهداري آن از نظر اقتصادي مقرون به صرفه باشد.
• طرز كار با سيستم ساده باشد.
• سيستم با كاربر آن ارتباط خوبي برقرار كند و راهنمايي هاي لازم را در مواقع مورد لزوم به كاربر بنمايد و كاربر پسند باشد.
• داراي سرعت كافي و مناسب در پردازش داده ها و ارايه گزارش هاي مورد نياز مدير در كوتاه ترين زمان ممكن باشد.
• مدير را دچار زيادي اطلاعات و آلودگي اطلاعات ننمايد
• سيستم انعطاف پذير باشد و بتواند همراه با تغييرات سازان، تغيير و بهبود يابد.
تحقيقات انجام شده نشان مي‌دهد با وجود پيشرفت هاي زيادي كه در عرصه دانش و مهارتهاي مرتبط با MIS و بهره گيري از اين ابزار خوب مديريت در كشورهاي توسعه يافته صورت پذيرفته، اجراي پروژه هاي مربوط در اين حوزه در كشور ما چندان موفق نبوده است.
در ايران بحث هاي مرتبط با حوزه فناوري اطلاعات رونق فراواني يافته است و تمايل سازمان‌هاي خصوصي و دولتي به اين مقوله و به ويژه به بحث استقرار سيستم‌هاي اطلاعات مديريت، بسيار قابل توجه بوده است.
اما بايد اذعان نمود كه عملكرد سيستم‌های MIS با ناكامي هاي زيادي همراه بوده و ميزان شكست جزيي و كامل اين سيستم ها در اين حوزه قابل توجه است. آنچه در اين ميان اهميت زيادي دارد، توجه به علت ها و عوامل بروز اين ناكامي ها و عدم موفقيت ها مي‌باشد. در واقع با شناخت و تبيين مسايل اساسي و با لحاظ نمودن نگرش سيستمي و بهره مندي از الگويي جامع براي بررسي پروژه هاي استقرار MIS در سازمان ها، مي‌توان فرايند توسعه آنها را در راستاي ديگر اهداف سازمان‌ها، اجرا نمود و به موفقيت هاي بيشتري دست يافت.
لازم به ذكراست كه آمار شكست و موفقيت پروژه هاي اجرا شده در حوزه فناوري اطلاعات در سال 2004 ميلادي در كشورهاي پيشرفته و توسعه يافته جهان نيز اين واقعيت را آشكار مي سازد كه تنها در حدود 15 درصد اين پروژه ها به موفقيت كامل دست يافته اند. يا به عبارتي ماهيت عملكرد نتايج پروژه ها، مطابق آنچه كه در طرحهاي اوليه و پيشنهادي براي اين پروژه ها به عنوان اهداف ترسيم گرديده بوده اند، نمي‌باشند. بر اساس تحقيقات انجام شده حدود 50 درصد اين پروژه ها با شكست جزيي و حدود 30 درصد آنها با شكست كامل مواجه شده اند. [9] و [10] و [11]
بر اساس مطالعات انجام شده از سوي كنت لاودن كه از صاحب نظران مشهور در اين زمينه مي‌باشد، عوامل مؤثر در موفقيت يا شكست يك سيستم اطلاعاتي را مي‌توان در سه حوزه فني، مديريتي و سازماني تقسيم بندي نمود. 
در تقسيم بندي ديگري كه توسط مديسون و دارنتون ارايه شده است عوامل مؤثر در موفقيت و شكست اين سيستم ها به عوامل فني، انساني، سازماني و محيطي تقسيم و معرفي شده اند. ضمن آنكه برخي از پژوهشگران مهمترين عامل را در اين رابطه، عامل انساني و رفتاري مي دانند. 
معيار ميزان شكست يا موفقيت پروژه ها مي‌تواند شكاف بين وضع مطلوب (برنامه ها) با طرح پيشنهاد پروژه پياده شده باشد. به عبارتي ديگر هرچه اين شكاف بيشتر باشد، احتمال ميزان شكست پروژه بيشتر شده و اگر اين فاصله از بين برود احتمال موفقيت پروژه بيشتر خواهد شد.
با نگرش سيستمي و جامع مي‌توان دريافت كه اين شكاف در حوزه هاي مختلف مي‌تواند حاصل شود. براي مثال اين شكاف مي‌تواند در موضوع هايي همچون فناوري، فرايندها، اطلاعات، ارزشها، مهارتهاي كاركنان، ساختار و سبك هاي مديريت به وجود آيد و عوامل متعددي مي‌توانند علل بروز اين شكاف باشند. [12]
ورود سيستم‌هاي اطلاعاتي به سازمان‌هاي كشور ايران به ويژه سازمان‌هاي دولتي، همواره موفقيت آميز و بدون دردسر نبوده است. در بسياري از موارد سيستم‌هاي ايجاد شده نتوانسته اند انتظارات مديران را برآورده سازند و همين عدم رضايت به هر حال باعث شده نه تنها مشكلات قبلي حل نشود، بلكه سيستم و سازمان دچار اختلال گرديده و علاوه بر صرف هزينه و وقت زياد از كيفيت و بازدهي آنها نيز كاسته شود. 
تجارب قبلي نشان مي‌دهد مشكلات در اين زمينه بيشتر جنبه مديريتي و ساختاري دارد تا فني، علت اصلي ناكامي اكثريت قريب به اتفاق سيستم‌هاي اطلاعاتي، عدم اجراي صحيح و كامل مراحل طراحي، ايجاد و بكارگيري اين سيستم ها به ويژه مرحله تجزيه و تحليل و بررسي اوليه بوده است. 
در بيشتر سيستم‌هاي ناموفق، يا بررسي اوليه انجام نشده و يا به طور بسيار ناقص انجام شده است. به ويژه آنكه عدم شناخت كافي استفاده كنندگان و همچنين تبليغات نادرست فروشندگان خدمات نرم افزاري نيز مزيد بر علت گرديده است.
عدم انجام كامل بررسي هاي اوليه موجب مي‌شود كه بستر اجراي سيستم‌هاي اطلاعاتي، مشخص و آماده نگردد و سيستم طراحي شده با ساير سيستم‌هاي موجود (به ويژه سيستم‌هاي سنتي و دستي) سازمان، هماهنگي و همخواني نداشته و نتواند به صورت مناسب با آنها ارتباط و داد و ستد داشته و مجموعه منظم و مفيدي را به وجود آورد.
مشكلي كه اغلب در اجراي موفقيت آميز مرحله تجزيه و تحليل و بررسي نيز وجود دارد، مسأله ارتباط تحليل گران (طراحان) با استفاده كنندگان (كاربران) سيستم است. به طور معمول كاربران شناخت كمي از رايانه و سيستم‌هاي اطلاعاتي دارند و تحليل گران نيز از امور سازمان‌ها آگاهي و شناخت اندكي دارند. اين مسأله موجب آن مي‌گردد كه سيستم‌هاي طراحي و اجرا شده به طور كامل پاسخگوي نيازهاي واقعي كاربران نباشند.
افزون بر مسايل فوق، شتاب مديران نه تنها براي ايجاد و راه اندازي سيستم‌هاي اطلاعاتي منفرد، بلكه نسبت به ايجاد(MIS)، همچنين كمبود منابع مالي، كمبود نيروي انساني كارشناس و باتجربه و كارآمد و با انگيزه نيز از عوامل ديگري هستند كه موجب گرديده اند تا سازمان‌هاي دولتي نتوانند آنگونه كه بايد و شايد از اين سيستم ها در سازمان‌هاي خود بهره گيري نمايند.
اگر از مجموعه نتايج تحقيقاتي كه صورت پذيرفته استفاده نموده و كليه موانع و مشكلات موجود بر سر اين راه به سه گروه عوامل انساني، عوامل سازماني و عوامل محيطي تقسيم گردند،

عمده ترين نارسايي ها و دلايل عدم موفقيت و بكارگيري سيستم‌هاي اطلاعاتي به ويژه MIS در سازمان‌هاي دولتي به شرح زير معرفي مي گردند:
الف) عوامل انساني:
• عدم آگاهي مديران و كاربران از اينكه به طور دقيق نمي دانند چه مي خواهند و چه نيازهاي اطلاعاتي دارند.
• عدم درك صحيح خواسته ها و نيازهاي كاربران توسط طراحان (عدم تعريف صحيح نيازها و تحليل آنها)
• درك نامناسب مديران از سيستم‌هاي نرم افزاري و اطلاعاتي
• عدم آشنايي بسياري از تحليلگران و برنامه نويسان(طراحان) با محيط كار سيستم جديد
• عدم پذيرش مجريان سيستم (راهبران) و بروز پديده مقاومت در برابر تغيير
• نبودن باور و نگرش كافي و مناسب در مديران ارشد و مياني براي بهره گيري از سيستم‌هاي اطلاعاتي مبتني بر رايانه به جاي سيستم‌هاي دستي
• نگراني مديران عالي از بابت كاهش ضريب حفاظتي اطلاعات در سازمان
ب) عوامل سازماني 
• عدم تناسب و پيچيده بودن سيستم‌هاي دستي موجود
• عدم انجام تجزيه وتحليل سيستم ها و روشهاي موجود قبل از طراحي سيستم
• عدم وجود معيارهاي مالي براي پروژه هاي سيستم هايي اطلاعاتي مديريت و تخصيص كمتر اعتبار براي پروژ هاي نرم افزاري به نسبت سخت افزاري
• پياده سازي نامناسب و ناصحيح سيستم
• آموزش ناكافي كاربران
• عدم انعطاف پذيري سيستم در حين بكارگيري
• موانع فناوري و ساختاري 
• وجود اشكال و نارسايي در نرم افزار مورد استفاده سيستم
• نبودن (كمبود) كنترل‌هاي مناسب از نحوه فعاليت كاركنان
• عدم وجود فرهنگ مناسب در به كارگيري سيستم‌هاي اطلاعاتي در سازمان ها
ج) عوامل محيطي:
• عدم وجود معيار سنجش كيفيت سيستم‌هاي اطلاعاتي موجود در كشور
• عدم وجود يا كم فعال بودن انجمن ها و كانون هاي علمي مرتبط
• عدم توجه جدي و كافي دولت و عدم سرمايه گذاري كافي در اين رابطه 
• پيشنهادهايي به مديران در خصوص پروژه استقرار و پیاده‌سازی MIS
• توسعه فرهنگ بكارگيري سيستم‌هاي اطلاعاتي در كشور به ويژه در سازمان‌هاي دولتي امري ضروري است. لذا مديران اين سازمان‌ها بايستي تمهيدات لازم براي برگزاري دوره‌هاي آموزشي مناسب را فراهم آورند.
• در طول فرايند طراحي، استقرار و بكارگيري MIS در سازمان، مديران سازمان‌ها مي‌بايستي به جنبه‌هاي رفتاري كاركنان سازمان و به ويژه راهبران سيستم توجه لازم و كافي داشته باشند و آنها را در فرايند ايجاد سيستم مشاركت دهند.
• مديران سازمان‌هاي دولتي بايستي تلاش نمايند جو اعتماد و اميد را در بين كاركنان سازمان و به ويژه متخصصان اطلاعاتي سازمان در فرايند استقرار و پیاده‌سازی MIS به وجود آورند و بين اهداف سازمان و اهداف كاركنان هم جهتي ايجاد نمايند.
• درك و شناخت صحيح نيازهاي اطلاعاتي مديران (كاربران سيستم) در هنگام تحليل و طراحي سيستم از اهميت ويژه اي برخوردار است، لذا پيش بيني فرصت كافي براي اين امر، ضروري و اساسي مي‌باشد.
• استقرار و پیاده‌سازی MIS مي‌بايستي به صورت گروهي انجام پذيرد و در تركيب تيم استقرار، علاوه بر تحليل گر، طراح سيستم و ...، فردي كه داراي دانش مديريتي و علوم رفتار سازماني باشد، مي‌بايستي حضور داشته .
• آموزش مديران (كاربران) و راهبران سيستم در فرايند ايجاد سيستم MIS از اهميت خاصي برخوردار است. طراحان سيستم مي بايست آموزش هاي مناسب با توجه به ويژگي‌هايي كه مديران و راهبران سيستم دارند را پيش بيني تا امكان رضايتمندي بيشتر آنان فراهم گردد.
• مديران كاربر سيستم و راهبران سيستم در طول فرايند توسعه سيستم، مشاركت داده شوند و تيم طراحي تركيبي از طراحان، كاربران و راهبران باشند.
• از آنجا كه محيط سازمان‌ها، فرايندها و عوامل داخل سازمان‌ها به صورت مستمر در حال تغيير مي‌باشند و اين امر باعث مي‌شود كه نيازهاي اطلاعاتي مديران تغيير يابد، لذا بايد طراحي و بهينه سازي يك MIS مناسب را در سازمان، فرايندي مستمر دانست. لذا طراحان بايستي قابليت تطبيقي لازم و انعطاف مناسب را در سيستم خود پيش بيني نمايند.
برگرفته از وبلاگ تخصصی مديريت آموزشی

تصویر اميد دباغ
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط اميد دباغ - دوشنبه، 20 بهمن 1393، 01:43 ب.ظ
  نام پروژه : healthcare.gov

سایت برنامه یارانه سلامت و بهداشت دولت اوباما موسوم به Obamacare تحت آدرس healthcare.gov بدلیل ترافیک بالا برای بعضی شهروندان امریکایی دور از دسترس قرار گرفت و یا اگر بود، ثبت نام در آن به سختی صورت می گرفت. این عامل سبب شد تا شهروندانی هم که در ابتدا ثبت نام کرده اند هنگام ورود مجدد با پیغام پسورد اشتباه روبرو شوندو آنها برای حل مشکلات ساختاری در پایگاه اینترنتی مجبور به ریست کردن reset password‌ پسوردها شدند. پروژه پایگاه اینترنتی ۴۰۰ میلیون دلاری دولت الکترونیک اوباما برای عرضه یارانه سلامت و بهداشت برای شهروندان متقاضی دچار مشکل شد و با حل یک مشکل فنی در پایگاه اینترنتی، مشکل دیگری بروز می کرد. بر این اساس ۷۰ درصد از پروژه فقط تکمیل شده و ۳۰ درصد باقی مانده هنوز معلوم نیست در چه بازه زمانی تکمیل شود و این در حالی است که به مردم گفته شده برای ثبت نام و دریافت خدمات دولتی که باید از ژانویه ۲۰۱۴ آغاز می شد، وارد پایگاه اینترنتی شده و ثبت نام کنند. بر طبق مدارک موجود از پیمانکاران این پروژه، پلتفورم تعریف شده برای پایگاه اینترنتی مبتنی بر ویندوز سرور ۲۰۰۳ است و پیربودن سیستم تعریف شده با توجه به اینکه اغلب نیروهایی که باید با سیستم کار کنند بالای ۴۸ سال سن دارند، نیز به مشکل افزوده است. دولت امریکا و نهادهای وابسته هنوز با ویندوز ایکس پی و ویندوز سرور ۲۰۰۳ کار می کنند و این در حالی است که اخطارهای امنیتی در مورد ایکس پی بارها از سوی آژانس های امنیت اطلاعات اعلام شده است. در مورد پروژه اخیر و مشکلات رخ داده، دولت اوباما برای حل این مشکل بین دو هفته تا دو ماه زمان خواست تا بتواند مشکلات را رفع کند در حالی که کارشناسان آی تی می گویند مشکلات پروژه به این زودی ها حل نمی شود. (گفتنی است برنامه Obamacare یا Health Insurance marketplace با هدف کمک به شرکت های بیمه مطابق با قوانین حمایت از مصرف کنندگان، رقابت مقرون به صرفه و گسترش پوشش بیمه ای به مردم بیشتری از ایالات متحده تعریف شده است و به صورت منطقه ای بسته های بهداشتی و سلامتی را برای شهروندان مطابق با درآمدشان بعد از ثبت نام پیشنهاد می کند و اگر خانواده ای شایستگی دریافت بسته رایگان و خدمات پزشکی ودرمانی رایگان را داشته باشد، بعد از تشخیص توسط مقامات محلی و از طریق شرکتهای بیمه می تواند از این نوع خدمات استفاده کند. این بسته ها بر اساس اطلاعات شهروندی هنگام ثبت نام در پایگاه اینترنتی healthcare.gov تقسیم و توزیع شده و از اول ژانویه ۲۰۱۴ لازم الاجرا برای همه است. بنابر بسته های این طرح، مردم در نهایت با پرداخت کمتر از طریق بیمه ها، ارزان تر به خدمات بهداشتی و درمانی متناسب با درآمدشان دسترسی پیدا می کنند.)
تصویر مليحه خليلي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط مليحه خليلي - سه شنبه، 21 بهمن 1393، 01:30 ب.ظ
 

این مطالب از زبان یکی از اعضای این پروژه(احسان میرسعیدی) که به عنوان برنامه نویس فعالیت میکرد بیان شده است،که بخاطر اینکه این پروژه،یک پروژه ملی بوده از توضیح مشخصات بیشتر خودداری کرده است ولی من از جهت اینکه دلایل شکست را بخوبی شرح داده است،از آن استفاده کردم.

· * مشخصات و هدف پروژه: این پروژه قرار بود زیرساخت های یک سازمان عریض و طویل کشوری را دگرگون کندپروژه ای ERPمانند بود و قرار بود عمده کار تحت بستر وب توسعه پیدا کند.

تقریبا از شهریور ماه سال 91 درگیر یکی از پروژه های ملی و بزرگی شدم که اگر درست و صحیح به ثمر می رسید، می توانست تغییراتی بنیادین، ساختاری و مدرن را در بدنه یکی بزرگ ترین سازمان های مهم و حیاتی کشور اعمال کند. متاسفانه این پروژه به دلایل مختلفی به عقیده من شکست خورده است و تا تغییرات اساسی در نحوه فرایند تولید نرم افزار ایجاد نشود، کار برای همیشه زمینگیر خواهد شد و یا در بهترین حالت پولی از بیت المال صرف نرم افزاری می شود که کوچک ترین کارایی و کیفیتی نخواهد داشت.

· * دلایل شکست پروژه: در ادامه دلایلی را که به عقیده من منجر به شکست پروژه شده است را تشریح خواهم کرداین دلایل هیچ تقدم و تاخری ندارند و هر کدام از آن ها می تواند به تنهایی یک پروژه را زمین گیر کند.

همه آنچه که در زیر می آید، در یک کلام خلاصه می شود و آن حرفه ای نبودن است. نرم افزار خوب و با کیفیت از آن دست محصولاتی نیست که برای تولید اش راهی به جز حرفه ای بودن وجود داشته باشد. حرفه ای بودن یک شرکت - مخصوصا در مقیاس پروژه های ملی- نه تنها در زمینه توسعه و کدنویسی خود را نشان می دهد، بلکه حرفه ای بودن بایستی در تحلیل ها و طراحی ها، در مصاحبه ها و نیازسنجی ها و مدیریت مشتری، مدیریت تیم نرم افزاری، مدیریت پروژه و دانستن نحوه رفتار با توسعه دهندگان و باقی مسائل حرفه ای منعکس گردد. آیا می توان یک پروژه ملی را بدون در نظر نگرفتن استاندارد ها و کیفیت پیش برد؟

1 . ابزارهای توسعه بی کیفیت

برای توسعه این سامانه از ابزاری به نام Wavemaker استفاده شده است. این ابزار اگر چه از فریم ورک های مهمی چونHibernate و Spirng و Dojo بهره می گیرد اما به طور کلی ابزاری است که کاری جز خراب نمودن و کند کردن روند کار شما نخواهد داشت. این ابزار اگر چه ادعا می کند که از نوع RAD می باشد، اما هنر اصلی این ابزار ارائه کاری بی کیفیت، غیر قابل پیشبینی و زشت و برهنه (البته از لحاظ امنیتی!) است که در زمانی بسیار بیشتر از حداکثر زمان ممکن، طراحی و توسعه داده می شود.

2. کم مهارت بودن اعضای تیم

پروژه هایی در این سطح نیاز به افراد متخصص و حرفه ای دارند. متاسفانه افراد تیم ما، افرادی بودند که سابقه چندانی نداشتند.اگر نگوییم اولین پروژه، که اولین پروژه جدی و بزرگشان، همین پروژه بود. همین باعث شد در بسیاری از مواقع، کارها دچار دوباره کاری، کثیف کاری و ندانم کاری ها شود و روند توسعه به شدت کند و بی کیفیت گردد. همین باعث شد تا نرم افزاری توسعه داده شود که در بسیاری از قسمت ها، بارها و بارها از صفر نوشته شد، بسیاری از قسمت ها بی کیفیت و کند بود و یا اینکه هر کسی نمی توانست بر روی قسمتی که کسی دیگر کار کرده است کار کند.

3. کم بودن نفرات تیم

به تجربه برای من ثابت شده است که برای انجام کار با کیفیت، سازمان بایستی به طور با کیفیتی پول هزینه کند. یکی از موارد این هزینه ها هم، استخدام تعداد پرسنل کافی و حرفه ای است. این پروژه دارای گستردگی بالا، تعدد ذینفعان، نقش ها و نیازمندی های مختلفی بود. به همین دلیل به باور من، تیم ما در قسمت نیازسنجی، حداقل به چهار نفر نیاز داشت. اما در بیشتر دوران این ده ماه، کل تیم فقط از سه نفر تشکیل شده بود. گاهی هم نفر دیگری به پروژه اضافه می شد و مسئولیت استخراج نیازمندی ها را بر عهده می گرفت. یکی از علل عقب افتادن تحویل پروژه و بی کیفیتی کار، این بود که این پروژه به شدت از کمبود نیرو رنج می برد.

4. ضعف در استخراج نیازمندی ها

عامل شکست بیش از هشتاد تا نود درصد پروژه ها، ضعف در تحلیل نیازمندی ها می باشد. بلایی که گریبانگیر این پروژه هم شد. در مراحل اولیه از سمت شرکت اجازه استخراج نیازمندی ها به ما داده نشد. حتی در جلسه ای که با یکی از ذینفعان بود، من تعدادی سوال در رابطه به نیازمندی های شان پرسیدم که بعدا مواخذه شدم. در سه ماه اول، نیازمندی ها از طرف شخص ثالثی که دید و شناخت بسیار محدودی از پروژه داشت، به ما ارائه می شد. مطالبی که به دست ما می رسید، بسیار آشفته و سردرگم و پر از ابهام بود و مرجعی هم برای پاسخگویی به سوالات و رفع ابهامات تیم وجود نداشت. حاصل کار هم چیزی جز دوباره کاری و سردرگمی نبود. ماحصل کار هم پس از سه ماه به سطل آشغال ریخته شد.

آن فرد کنار رفت و فرد دیگری به تیم ما اضافه شد و مسئولیت مصاحبه ها و استخراج نیازمندی ها را بر عهده گرفت. این فرد، متاسفانه پیش از این هیچ سابقه ای در نیازسنجی نداشت و نبایستی تمامی این کار در اختیار و حیطه مسئولیت این فرد، به تنهایی، قرار می گرفت. او نتوانست که اطلاعاتی را که در مصاحبه و جلسات کسب کرده مکتوب کند و در اختیار تیم بگذارد. او نتوانست در مصاحیه هایش تفکرات ناصحیح کارفرما را اصلاح کرده و به او دید صحیح بدهد.

این ها نمی دانستند که نرم افزار قلمرو ابهامات نیست، که جایگاه جزییات و دقت هاست.

5. حقوق پایین و حتی عدم پرداخت

همانطور که بیان شد، کار با کیفیت نیاز به خرج با کیفیت دارد. متاسفانه بازه حقوقی کارکنان بسیار پایین بود. با توجه به حجم و زحمت کار، نیاز به دریافت مبلغ بیشتری بود تا کارمندان انگیزه تحمل فشارها و ناملایمت های محیط کار را داشته باشند. اما متاسفانه به علت پایین بودن حقوق ها، به مرور انگیزه ها کم شد و تیم دچار فرسایش روحی و انگیزشی شد. دیگر به جایی رسیدیم که در شرکت عملا کاری انجام نمی گرفت. عامل دیگری که باعث کاهش انگیزه پرسنل می شود، مقایسه خود با همکاران در شرکت های دیگر است. که این مقایسه خواه ناخواه صورت می گیرد.

6. دروغگویی در جلسات

یکی از عواملی که باعث شد که اعتبار شرکت نزد کارفرما ضربه بخورد، دروغ گویی های بی حد و حصر مدیران در جلسات بود. مدیری در جلسات حضور می یافت و در صورتی که نرم افزار را ندیده بود، چنان از ویژگی های عجیب و غریب سامانه و هزینه های هنگفتی که برای آن شده است، سخن می گفت که ما خودمان حیرت می کردیم.

7. ارائه تخمین های غلط به کارفرما

هم کسی که مدیر پروژه شده بود و هم مدیرانی که در جلسات شرکت می کردند، بسیار وعده های عجیب و غریبی نسبت به زمان آماده سازی برخی قابلیت ها می دادند. قول هایی که داده می شد مبتنی بر واقعیت های تولید نرم افزار نبود و زمانی که لازم است تا چرخه استخراج نیازمندی، تحلیل و پیاده سازی و تست طی شود را درنظر نمی گرفت. این تخمین های ناصحیح باعث می شد تا شب های زیادی تیم در شرکت بماند و یا بالاجبار روزهای تعطیل بیاید و اضافه کاری های سنگیی را متحمل شود. البتهدر پروژه ما، نتیجه همه این شب کاری ها و اضافه کاری ها، در نهایت دور ریخته شد. چرا که کارمندان تحت فشار ،کار با کیفیت تولید نمی کنند.

8. مهارت و تعهد پایین مدیران

شرکت دارای دو مدیر فنی بود. هر دو از تحصیل کردگان شاخص دانشگاه امیرکبیر در رشته هوش مصنوعی بودند. متاسفانه نفر اصلی به ندرت در شرکت حضور داشت و در جریان کارها و هماهنگی های پروژه نبود. دیگری هم بیشتر درگیر کارهای شخصی خودش بود. آگاهی ای نسبت به ظرافت کاری های پروژه و موانع و مشکلات آن نداشتند.

9. عدم احترام به پرسنل

موضوعی که همه پرسنل نسبت به آن ناراضی بودند، عدم رعایت احترام آن ها از سمت مدیران بود. اگر چه شرکت از جهات مختلف دارای ضعف های عمده بود، اما مدیریت به جای اینکه با رفتارش کارمندان را جذب کند به نوعی موجب دلسردی آن ها شده بود. نگاهی از بالا به کارمندان داشتند. صدای انتقادات آن ها شنیده نمی شد و نتیجه هم جز این نبود که همین موجب ایجاد نارضایتی زیادی در کارمندان شد و این نارضایتی در کاری که انجام می دادند منعکس شد. حلقه معیوبی از نارضایتی شکل گرفت که مدام تشدید می شد. همچنین عدم حل مشکلات در بالا و ایجاد محدودیت برای کارمندان موجب شد، تا به جای اینکه ذهن کارمندان آرامش داشته باشد، مدام درگیر و دار ناراحتی و نارضایتی باشد.

10. عدم تعهد پرسنل به انجام کار خوب

از ویژگی های مهمی که باعث می شود تا هر کس در کارش پیشرفت کند، تعهد می باشد. تعهد به انجام کار خوب و باکیفیت فرد را در مسیر حرفه ای رشد می دهد. این ویژگی در فرد موجب می شود تا کاری که آماده می کند بهترین کیفیت ممکن را داشته باشد و مطمئن باشیم که فرد به همه وجوه مختلف آن فکر کرده است. متاسفانه اعضای این پروژه این تعهد حرفه ای را به خود، تیم و پروژه نداشتند. موجب شد در مدت این ده ماه نه چیزی به دانش شان اضافه شود و نه کاری که آماده می کنند دارای کیفیت شاخص و ممتازی باشد.

11. عدم وجود تست

در مورد عدم وجود تست پلن و مسائل مربوطه نیازی به توضیح نیست. آیا انجام پروژه بزرگ، بدون وجود انواع و اقسام تست های حرفه ای ممکن است

12. عدم مستند سازی

در این پروژه بعد از ده ماه، هنوز یک صفحه مستندات آماده نشده بود تا بدانیم هر ذینفعی دارای چه نوع نیازمندی هایی می باشد. این هم به این معنی است که بر روی هیچ یک از نیازمندی ها توافق قطعی صورت نگرفته بود. در نتیجه نه نیازسنج ما راهی داشت تا بفهمد که سخنان کارفرما را به درستی درک کرده و نه کارفرما راهی داشت که بداند آیا سخنان اش را کامل و به درستی منتقل کرده است. سندی آماده نبود که بر طبق آن سامانه طراحی شود. این موجب شد که اگر جایی خطایی در طراحی و پیاده سازی انجام می شد و یا موضوعی فراموش می شد، نتوانیم با مقایسه با سند نیازمندی کارمان را ارزیابی کنیم. این امر هم باعث شد تا بسیاری از قابلیت ها در نرم افزار توسعه داده شود که بعد ها کارفرما ادعا کرده آن ها را نمی خواهد و یا منظورش جور دیگری بوده استبسیاری از قابلیت ها از جلساتی که با مدیران داشتند بیرون آمد. در این جلسات به طور آنی و بدون فکر قبلی بسیاری از ایده ها مطرح می شد و شخص نیازسنج بدون هیچ گونه تحلیل و مکتوب نمودن، آن ها را در طراحی سامانه منعکس می کرد. همین هم باعث شد، تا این ایده های ناقص الخلقه با ورود شان به سیستم تنها انرژی، انگیزه و پول تیم را هزینه کنند، بدون اینکه هیچ ارزش افزوده ای به پروژه اضافه کنند.

13. عدم وجود متدلوژی برای توسعه نرم افزار

توسعه نرم افزار، بسیار وابسته به نحوه تعاملات اعضای تیم و رابطه اصولی و تدوین شده کارفرما و پیمانکار می باشد. پروژه های بزرگ نرم افزاری را نمی توان به سبک یک هیئت اداره کرد و انتظار داشت تا همه چیز طبق برنامه و خواست ذهنی ما پیش برود. بسیار بسیار پیشتر، بزرگان این صنعت در غرب این مسیر را طی کرده اند و از شکست های شان آموخته اند که باید پروژه های نرم افزاری بر اساس قاعده و اصول خاص و مشخصی در حیطه تولید، تعاملات داخلی و خارجی پیش برد. یادگیری اصولی و رعایت این قوانین و چارچوب ها در کتاب ها پیدا نمی شود. نمی توان صرفا با مطالعه کتب مختلف راجع به SCRUM، به مدیریت نکات و نقاط بحرانی پروژه واقف شد. چرا که هر پروژه شرایط خاص خودش را دارد.

کارها در شرکت نظم و ترتیب مشخصی برای انجام نداشت. کارها زمان مشخصی برای پایان نداشت. برای همین کار برای مدت ها در شرکت به حال خود رها میشد. نبودن milestone و نداشتن deadline تیم را تنبل و بی انگیزه می کند. تیم برای جنگیدن بهانه و انگیزه ای نخواهد داشت و این اتفاق تیم را سست می کند. از طرف دیگر، نداشتن نظم موجب می شد تا کارفرما ناگهان اعلام کند که درخواست های زیادی را که در گذشته مطرح کرده برای یکی دو روز آینده می خواهد. این موجب میشد تا تیم از خواب خرگوشی بلند شود و شب و روز در شرکت بماند تا کار را تحویل دهد.

· * نتیجه ای که من از این مطلب گرفتم این است که از این 13موردی که نویسنده به عنوان دلایل شکست پروژه مطرح کرده است میتوان گفت تقریبا نیمی از آنها به دلیل عدم نیازسنجی صحیح اتفاق افتاده است.

نداشتن برنامه ریزی دقیق و عدم جمع آوری اطلاعات مورد نیاز قبل و در حین پروژه باعث بهم ریختگی و به نتیجه نرسیدن تلاش های تیم شده است.

 

تصویر دستيار استاد- مرتضي معلق
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط دستيار استاد- مرتضي معلق - دوشنبه، 27 بهمن 1393، 12:43 ب.ظ
  با سلام
سرکار خانم خلیلی
مطلب فوق العاده و جالبی بود. امیدوارم با مشارکت بیشتر زمینه همفکری و انتقال بهتر مطالب را فراهم کنیم.

موفق باشید
تصویر مليحه خليلي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط مليحه خليلي - پنج شنبه، 30 بهمن 1393، 10:23 ق.ظ
  استاد ممنون از توجه شما 
چشم حتما
تصویر ليلا ملك لو
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط ليلا ملك لو - سه شنبه، 21 بهمن 1393، 09:30 ب.ظ
  گوگل ويو – google wave


در ایمیل، ارتباط غیرفعال passive است. به این معنی که وقتی شما ایمیل دریافت می‌کنید، اجباری برای پاسخ دادن به آن در همان لحظه ندارید. توییتر از این لحاظ، نوع غیرفعال‌تری از ارتباط است، چون اکثر توییت‌ها به منظور دریافت پاسخ، ارسال نمی‌شوند.
اما در هنگام چت و استفاده از سرویس‌های پیام‌رسانی بی‌درنگ، نوع ارتباط جبری aggressiveاست. یعنی شما اگر on باشید و بعد دوستتان روی چت ظاهر شود و سوالی بپرسد،اجباری براي پاسخ دادن در همان لحظه داريد. اما گوگل ویو می‌کوشيد که الگوی تازه‌تری ار ارتباط را همگانی کند: ترکیبی از ارتباط غیرفعال و ارتباط جبری! از این نظر گوگل ویو دقیقا شبیه فرندفید بود.
Google Wave تركيبي از سرويس هاي مسنجر، ايميل، شبكه هاي اجتماعي محسوب مي شد . Wave اولین بار در سال 2009 معرفی شد و در ماه می سال 2010 شروع به کار کرد. 
مجموعه اي از قابليتهاي بي فايده که با يک روش پيچيده و غير لازم دور هم جمع شده اند. گوگل موج مي خواست براي همه، همه چيز در حوزه اشتراک محتوا باشد. همان طور که گوگل پلاس تلاش مي کند براي کاربران شبکه هاي اجتماعي همه چيز باشد. 

این برنامه با هدف به روز رسانی یا همان Update بسیاری از برنامه های اجرایی طراحی شد. در واقع این برنامه با اطلاع رسانی درباره به روز کردن برنامه هایی هم چون ایمیل قصد داشت کاربران را در جریان جدیدترین تکنولوژی ها بگذارد و این کار را توسط ارسال پیام هایی جداگانه و کوتاه انجام می داد .

اما گوگل تنها سه ماه پس از راه اندازی این سیستم ارسال پیغام و بدلیل عدم استقبال کاربران، اعلام کرد که تا پایان سال میلادی به کار آن خاتمه خواهد داد. 

از جمله عوامل عدم پیشرفت Wave می توان به عدم شناخت مردم نسبت به این سرویس و یا عدم آشنایی کاربران نسبت به کارد آن اشاره کرد. 
البته واضح است که گوگل موج اين قدرها هم بد نبود ولي مشکل آن همان مشکل اشتباه در پيش بيني نيازهاي کاربران بود.


تصویر پري ناز فتحي ورزقاني
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط پري ناز فتحي ورزقاني - چهار شنبه، 22 بهمن 1393، 05:27 ب.ظ
  ITLL :  Information Technology Infrastructure Library
بزرگترين چالش شرکت ها و سازمان هاي سرويس دهنده خدمات فن آوري اطلاعات، صرف کمترين هزينه ممکن و ارائه بهترين کيفيت مي باشد . اين امر در بخش هاي مختلف سازمان نمود پيدا مي کند که از آن جمله مي توان به مواردي چون افزايش بهره وري نيروي انساني، استفاده بهينه از ظرفيت هاي موجود و ايجاد امکانات و ظرفيت هاي جديد منطبق بر نياز واقعي کسب و کار اشاره نمود. در اختيار داشتن تکنولوژي پيشرفته و نيروي انساني متخصص به تنهايي کارگشا نبوده و مساله بسيار مهمي بنام روال هاي مديريت سرويس مطرح مي گردد که در واقع حلقه مرتبط کننده تکنولوژي و افراد مي باشد . براي رسيدن به اين اهداف، در دو دهه اخير فعاليت هاي بسياري در زمينه مديريت سرويس هاي IT در دنيا صورت گرفته و روشها و توصيه هاي گوناگوني ارائه شده است 
از ميان اين روش ها، ابتکار سازمان OGC  انگلستان، ITIL ، با گذشت حدود 20 سال از اولين تلاش ها، به عنوان استاندارد پذيرفته شده در دنياISO2000) ) در مديريت سرويس هاي IT مطرح مي باشد. ITIL  يك روش يا توصيه پيشنهاد شده توسط يک سازمان يا موسسه نيست، بلکه مجموعه اي از بهترين تجربيات شرکت هاي بزرگ دنيا طي سالهاي گوناگون در مديريت سرويس هاي IT مي باشد.
ITIL نه تنها داراي چارچوبي تئوري مي‌باشد بلكه رويكرد و فلسفه آن مشتركاً توسط افرادي كه در ايجاد اين تجارب سهيم مي‌باشند روز به روز اصلاح و توسعه می یابد.

هدف اصلی : 
شناسایی عوامل موفق  موثر  بر پیاده سازی پروژه ITIL در سازمان و همچنین شناسایی چالشها  پیاده سازی چارچوب ITIL در حوزه ساختار و سازماندهی منابع انسانی فناوری اطلاعات 
اهداف فرعی:
• شناسایی افزایش رضایت مشتری از خدمات IT
• شناسایی کاهش ریسک روبه‌رو شدن با نیاز‌هایی که تا به حال شناسایی نشده‌اند
• شناسایی کاهش هزینه‌ها
• شناسایی ارتباطات و انتقال اطلاعات بهتر بین مشتری و ارائه دهنده خدمات IT
• شناسایی استانداردهای معتبر برای ارائه‌دهنده‌گان خدمات IT
• شناسایی توانایی تولید بیشتر و استفاده بهتر از مهارت‌ها و تجارب
• شناسایی روشی با کیفیت برای خدمات IT
• شناسایی تطبيق فرايند كسب و كار با IT) IT براي كسب و كار نه IT براي IT)
• سازماني كارا
• شناسایی سازگاري پروژه با استاندارد ISO 2000
• شناسایی افزايش پايايي و توان عملياتي خدمات
• شناسایی بهينه سازي استفاده از منابع
نتیجه اجرای پروژه 
• کیفیت خدمات ارائه¬شده توسط فناوری اطلاعات به سایر واحدهای سازمان، در صورتی¬که از قابلیت¬های کارکنان به بهترین نحو استفاده شود، افزایش خواهد یافت. این امر بهبود مستمر را امکان¬پذیر می¬سازد. پیاده¬سازی موفق چارچوب ITIL در سازمان، مستلزم مشارکت و تعهد کارکنان تمام سطوح سازمان است. بدون توجه به آموزش و فرهنگ¬سازی کارکنان عملا نهادینه¬سازی سیستم مدیریت خدمات در سازمان غیر ممکن خواهد بود.
مهمترین عناوین و دلایل شکست پروژه های ITLI  اشاره شده است :
1. فقدان حمایت مدیریت ارشد
2. صرف زمان زیاد بر دیاگرام‌های پیچیده فرایندها
3. عدم ایجاد دستورالعمل‌های کاری
4. عدم تخصیص مناسب مالکین فرایند
5. تمرکز زیاد بر عملکرد
6. سعی در پیاده‌سازی حجم زیادی از فرایندها در گام ابتدایی پروژه
7. شکست در حفظ آهستگی و پیوستگی پروژه پیاده‌سازی ITIL
8. غفلت از دیگر چارچوب‌های همسو با ITIL که پیاده‌سازی این چارچوب را تقویت می‌بخشد. مانند COBIT, Six Sigma, CMMI, …
9. آشنایی محدود با چارچوب ITIL
10. پیاده‌سازی این چارچوب با هدف تحقق اهداف زیرساختی
11. توسعه نادرست و ناکارآمد نمونه تجاری
12. مدیریت پروژه ضعیف
13. عدم توجه به نیروی انسانی درگیر در پروژه و تمرکز بیش از حد بر فناوری
14. نیروی انسانی درگیر در پروژه بیش از حد در کارهای جاری و روزمره خود درگیر هستند و وقت آزادی برای انجام پروژه ITIL ندارند.








تصویر نيلوفر عمويي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط نيلوفر عمويي - پنج شنبه، 23 بهمن 1393، 03:26 ق.ظ
  نرم افزار پیامک فارسی
مشخصات پروژه: ارسال پیامک های فارسی با حجم حدود 200 کاراکتر با پرداخت هزینه تنها یک پیامک
اهداف پروژه: کاهش هزینه پیامک های ارسال شده توسط جلوگیری از شکسته شدن آنها به چندین پیامک
نتیجه اجرای پروژه: دریافت نکردن گزارش ارسال (delivery report) پیامک‌ ها توسط مشترکان همراه اول، و عدم‌تطابق نرم‌افزار پیامک فارسی با برخی گوشی‌های خاص، و همچنین اینکه این نرم‌افزار زمانی قابل استفاده بود که هم در گوشی فرستنده و هم در گوشی گیرنده نصب شده باشد، این در حالی است که در بسیاری از گوشی‌ها نمی‌ شد این نرم‌افزار را نصب کرد و این دوطرفه بودن یکی از مهم‌ترین دلایل استقبال نشدن از این نرم‌افزار بود. بعلاوه، با دریافت پیامک، نرم‌افزار به‌صورت خودکار هشدار نمی داد و منتظر بود تا کاربر به آن اجازه اجرا شدن بدهد. یعنی باید همیشه چشمش به صفحه گوشی بود که آیا پیامی دریافت کرده است یا نه. از ایرادات اساسی دیگر، عدم‌ارتباط با دفترچه تلفن گوشی تلفن همراه بود. و نیز کاربر باید دارای حافظه قوی برای‌ حفظ شماره‌های موردنظر خود بود و نمی‌توانست به راحتی جمله پیش فرض را اصلاح یا پاک کند و حتما باید دکمه گزینه را فعال و سپس گزینه پاک کردن را انتخاب کرده و دوباره به صفحه تایپ وارد می شد.از نقاط ضعف دیگر، عدم‌ کاربرد آن برای سیم‌کارت‌های اعتباری دولتی و پیاده نشدن آن روی گزینه ارسال پیام کوتاه در گوشی‌ها بود. پیامک‌های حاوی تصویر به‌عنوان پیام لاتین محسوب می‌شدند، زیرا فرمت آنها لاتین بود، مگر اینکه در نرم‌افزار پیامک فارسی این امکان وجود داشته باشد که تصاویر و عکس‌ها را با فرمت فارسی محاسبه کند که در آن‌ صورت وضعیت تعرفه‌ها تغییر می‌کرد.
درس هاي گرفته شده از پروژه: بهتر بود به جای افزایش تعرفه پیامک لاتین برای برخی از مشترکانی که گوشی آنها امکان ارسال پیامک فارسی ندارد و فاقد حافظه برای دانلود نرم‌افزار پیامک فارسی است، میزان کاراکترها کاهش می‌یافت، به این معنا که در حال حاضر که در پیامک لاتین 160 کاراکتر به‌عنوان یک پیامک محاسبه می‌شود، این میزان را 80 کاراکتر می‌کردند که در این صورت مشکل این گوشی‌ها‌ نیز حل می‌شد تا این دسته از مشترکان مجبور نشوند به‌عنوان مثال برای ارسال پیام یک کلمه‌ای هزینه 222 ریالی پرداخت کنند. همچنین جا داشت تا سازمان بازرسی در حمایت از حقوق مصرف‌ کنندگان قبل از فشار برای کاهش تعرفه پیامک فارسی در گام اول به تحقق موضوع واردات گوشی‌های منطبق با خط فارسی اقدام می‌کرد و چنانچه در این خصوص به موفقیتی دست نمی‌ یافت، حداقل دولت را مجبور به کاهش تعرفه پیامک لاتین تا زمان کنترل واردات گوشی‌های متناسب با خط و زبان کشور می‌کرد.
تصویر هه ژار اسمعيل زاده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط هه ژار اسمعيل زاده - پنج شنبه، 23 بهمن 1393، 08:37 ب.ظ
  شکست واژه ای است که هیچکس دوستش ندارد و از پذیرفتن آن طفره می رود اما این روزها می شنویم که غول اینترنتی دنیا برای شکست های معدودش هم جشن می گیرد! بله گوگل برای شکست پروژه هایش جشن می گیرد، انگار دوست ندارد خودش را از تک و تا بیندازد. نمی دانم اثرات این جشن گرفتن چیست ولی احتمالا منظورشان همان "شکست مقدمه پیروزی است" باشد
تصویر هه ژار اسمعيل زاده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط هه ژار اسمعيل زاده - پنج شنبه، 23 بهمن 1393، 08:47 ب.ظ
  اگر برای همه واضح باشد که یک پروژه شکست خورده است باز هم مسئول مربوطه مصاحبه می کند و امیدواری می دهد که آن پروژه به زودی به اتمام خواهد رسید نمونه هایش فراوان است ولی موضوع بحث ما صرفا شکست های نرم افزاری و IT است. البته تعداد شکست های اینگونه در ایران به دلیل فقر نرم افزاری، سخت افزاری و انفورماتیک کشور کم است ولی این امر دلیل نمی شود تا از آنها نامی به میان نیاید. با هم تعدادی از آنها را مرور می کنیم:
نرم افزار پیامک فارسی:
طرحی که گمان می‌رفت قادر است هزینه دوبرابری پیامک فارسی برای مشترکان همراه اول را به نصف کاهش دهد عملا با شکست مواجه شده است.
که پروژه های نرم افزاری دیگری نیز وجود داشتند که با شکست مواجه شدند که این شکست ها با پیدایش نرم افزارهایی مثل وایبر و واتس آپ و ... صورت گرفته و حتی هزینه تماس با تلفن همراه نیز کاهش یافته و از طریق اینترنت صورت می گیرد که این نیز خود ضربه شدیدی به مخابرات وارد کرده است.
تصویر هه ژار اسمعيل زاده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط هه ژار اسمعيل زاده - پنج شنبه، 23 بهمن 1393، 08:52 ب.ظ
  Nokia N-gage

گوشی موبایل و پلتفرم بازی را در یک دستگاه داشتن واقعاً ایده آل به نظر می رسد ولی بازار چیز دیگری نشان داد. Nokia N-gage همانطور که از نام آن پیداست در سال ۲۰۰۳ توسط کمپانی نوکیا عرضه شد و با تبلیغات گسترده ای که انجام داد انتظار می رفت بازار را به قبضه خود در آورد. ولی با تمام این تدابیر فروش آن در کمترین حد انتظار بود. یکی از علل عدم استقبال از این گوشی تعداد انگشت شمار بازی های مناسب برای آن بود.
تصویر ام البنين جوشني نوقابي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط ام البنين جوشني نوقابي - جمعه، 24 بهمن 1393، 11:00 ق.ظ
 

 



NOKIA

سرنوشت تلفن همراه نوكيا

-مشخصات پروژه :

  • شركت عمومي ومحدود بنا نهاده : تامپره، فنلاند (۱۸۶۵) ،‌نوکیا، فنلاند (۱۸۷۱) ،
  • صنعت :تجهیزات مخابراتی،فعاليت در حوزه‌های تجهیزات پهنای باند شبکه‌های موبایل و خدمات مولتی‌مدیا، غول موبایل جهان و وبزرگترین نوآور و قدیمی ترین شرکت موبایل جهان
  • محدودهٔ فعالیت :جهانی
  • راجیف سوری : مدیر عامل اجرایی

اهداف پروژه :

  • نوکیا به عنوان تکنولوژی مخابراتی رادیویی موبایل ارتش و تجاری تولید شد.
  •  تاسیس موبیرا اوی
  • توليد اولین گوشی‌های موبایل دنیا
  •  در سال ۱۹۸۷ نوکیا یکی از گوشی‌های همراه اولیه دنیا را معرفی کرد

نتيجه اجراي پروژ :

  • سازمان دهی مصرف کننده‌ها و بازاریان نوکیا و همچنین فروش‌ها،
  • شبکهٔ زیر بنایی ارتباطات تلفن همراه و سکوهای خدمات ارتباطی را، به خوبی خدمات رسانی حرفه‌ای برای اپراتورها و تهیه کنندگان خدماتخدمات شرکت‌هایی همجون سونی و سامسونگ و اچ تی سی و حتا اپل نیز هست.
  • قوی ترین سرویس نقشه (here)که دارای ۴۸ ماهواره

درس هاي گرفته شده از پروژه :(عدم نياز سنجي صحيح)

  • بی توجهی به گرایش عموم مردم به تلفن های لمسی
  • عدم توسعه یک اکوسیستم اختصاصی
  • عدم برنامه ریزی براي ایده های جدید
  • عدم همكاري در نوآوري باشركت هاي كوچك
  • عدم چابکی لازم را برای تغییرات سریع نرم افزاری وعملا کاربرانی را که به سرعت تغییرات اندروید و آی او اس عادت کرده بودند را از دست دادند.

 

در 2013بخش موبایل نوکیا به مایکروسافت منتقل شد. بدین ترتیب تولید گوشی‌های نوکیا با نام نوکیا میکرو سافت موبایل تولید می‌شوند (به مدت ۱۰ سال)


تصویر علي قلي زاده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط علي قلي زاده - شنبه، 25 بهمن 1393، 12:47 ق.ظ
  با سلام و احترام
عدم درک صحیح نیازمندی ها ، اتفاقی است که در بسیاری از پروژه ها روی می هد 
تجربه شخصی:
پروژه : سیستم ارتباط با مشتری CRM 
مقرر شده بود که جهت سهولت در امر مشتری مداری سیستم طراحی شود که فرم های شکایت و همچنین نظر سنجی های که در قسمت های مختلف بیمارستان ها وجود داشته اند بصورت کاملاً متمرکز وارد سیستم شده تا امر رسیدگی به این فرم ها با نیروی هرچه کمتر انجام گردد.
اهداف : طراحی نرم افزار CRM تحت وب با توجه به الزامات ISO10004:2012 و ISO 10002 
فرم های شکایت ها و نظر سنجی ها جهت بهینه بودن در قسمت بهبود کیفیت مورد بررسی و مطالعه قرار میگرفت وآن واحد با توجه به استانداردهای موجود در این زمینه به طراحی فرم ها و همچنین دسته بندی نمودن و ارجاعات به واحدهای مربوطه اقدامات لازم را انجام می داد
ما در این پروژه با توجه به دید نرم افزاری که داشتیم شروع به کسب نیازمندی های بیمارستان در این خصوص نمودیم و تمام موارد مورد درخواست بیمارستان را در یک جلسه به اتمام رساندیم
پس از اتمام پروژه و پایلوت نرم افزار به مدت یک هفته نشد که با کلی تغییرات روبرو شدیم تا آنجا که شد پروژه را تغییر دادیم تا رضایت بیمارستان را جلب نماییم اما گویا تغییرات پایانی نداشت
تصمیم گرفتیم برای درخواستها جلسه های تنظیم کنیم و موارد مورد درخواست رابصورت کتبی تنظیم و به امضاء مدیر بخش برسانیم
با بزرگ شدن سیستم تغییرات در یک بخش بسیار دشوار و زمانبر بود چرا که بخشهای دیگر را نیز بدلیل رابطه داشتن مجبور بودیم تغییر دهیم.

با تبلیغات موفق شدیم که با 5 بیمارستان در این خصوص همکاری نماییم ، با توجه به اینکه بنظرمان این سیستم اولیه که طراحی شده کامل بوده و دیگر نیاز به تغییرات نداریم و در روز های ارائه به مدیران بیمارستان قول customize کردن سیستم را مطابق با نظرات آنها می دادیم.

ولی هر بیمارستان روال خاصی برای گردش کار این روال داشت و ما در بعضی از مواقع مجبور به تغییر نمودن کلی نرم افزار و از نو نوشتن جهت برخی بیمارستانها را داشتیم
همین طور که به مشتریان ما اضافه می شد چندبرابر درخواست تغییرات به سمت ما ارجاع داده می شد که واقعاً برخی از درخواست ها غیر قابل اجرا و بسیار بسیار زمانبر می شد که حتی با افزایش نیرو به سختی از پس مشکلات بر آمدیم.
این در حالی بود که بدلیل زمانبر شدن تهیه نرم افزار بسیاری از مشتریان جدید خود را از دست داه چراکه در حال پشتیبانی مشتریان ابتدای خودمان بودیم 
با اینکه بازار و کسب مشتری درآن زمان برای ما بسیار آسان بود ولی بدلیل تحلیل و طراحی نامناسب از نیازمندی های سیستم CRM در بیمارستان ها نتوانستیم ادامه کار دهیم، که اگر یک سیستم CRM بصورت General که مورد درخواست اکثریت بیمارستان ها بوده میتوانستیم در این زمینه بسیار موفق باشیم.

همگام بردن نرم افزار با استانداردهای جهانی نیز کار را برای ما بسیار دشوار کرده بود چرا که برخی از این الزمات در سیستم نرم افزار قابل پیاده سازی نبوده یا اگر بوده سیستم را از ساختار نرم افزاری که می بایست کاربر پسند بوده خارج میکرد.
زمانی که به بررسی وقت و هزینه های انجام شده و میزان درآمد کسب شده پرداختیم واقعاً ارزش آن همه وقت و اعصاب خوردگی را نداشت 

درس هاي گرفته شده از پروژه:
1- حتماً و حتماً قبل از انجام پروژه جلسات متعددی را با مدیران،کارشناسان و بطور کلی ذینفعان پروژه ترتیب نمائید.
2-پس از اتمام جلسه حتماً صورت جلسه ای تنظیم نمائید و تمام موارد را کتباً به امضاء افراد حاضر در جلسه برسانید
3-قبل از شروع پروژه تیم پروژه خوبی از افراد توانمند تهیه نمائید
4- قیمت تمام شده را در ابتدا اعلام کرده و حتماً پیش پرداخت در ابتدای کار بگیرید
5-در تهیه پروژه بطوری عمل کنید که پروژه جنبه General داشته باشد (جهت ارائه آن به شرکتهای دیگر)
6-در تنظیم قرارد تمام موارد بصورت روشن و واضح قید نمائید
7- درخواستهای ارجاع داده شده به سمت شما اگر در تنظیم قرارداد نبوده به عنوان یک قرارداد جدید در نظر گرفته و هزینه و قیمت آن را حتماً لحاظ نمائید
با تشکر
تصویر شمين فاضلي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط شمين فاضلي - شنبه، 25 بهمن 1393، 10:36 ق.ظ
 

کمپانی راه آهن فرانسه SNCF و اپراتور ملی راه آهن RFF
نوع پروژه: قطار جدید
نام پروژه: 
Regiolis / Regio 2N
تاریخ: می 2014
هزینه: 15 بیلیون یورو

هدف از جرای پروژه رزرو و حرکت ساده تر و سریعتر مسافران در سراسر قاره بود.

RFF با دادن مقیاس اشتباه از اندازه ایستگاهها به کسانی که قطار را طراحی می کردند باعث این مشکل شد قطارهای ساخته شده از ایستگاهها بزرگتر بودند و درنهایت حق انتخاب داشتند تا با ساختن دوباره قطارها را هماهنگ با ایستگاهها کنند یا ایستگاهها را بازسازی کنند که طبق گزارشات تا به امروز با صرف 68 میلیون دلار هنوز نزدیک به 1000 ایستگاه بازسازی نشده اند.

کمبود داده و دانش به بروز این خطا کمک کرده است. اگر کاربران بخش در آن حوزه حضور داشتن و اپراتور و کمپانی جدا از هم نبودند امکان رویداد این خطا کاهش می یافت چون اینکار باعث شد یک رابط بین این دو سازمان وجود داشته باشد و احتمال اشتباه را بالا می برد. شناسایی ریسک و خطرات، نیاز به اختصاص زمان و منابع مختص خود را دارد.

تصویر سيما اسمعيلي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سيما اسمعيلي - يکشنبه، 26 بهمن 1393، 12:22 ب.ظ
 

مطالعه موردی کابوس ساله ERP، Overstock.com

Overstock.com شرکت تازه تاسیسی که از رقابت با آمازون باکی نداشت امروزه به دلیل صحبت های جسورانه بنیان گذارش Patrick Byrne، که شکست 14.2 ملیون دلاری را به سرمابه گذاران این شرکت اینگونه توضیح می دهد:"My bad"!

خرده فروشان آنلاین هم به دلیل تبلیغات اغواگرانه کمپین های شرکت به سمت آن کشیده شدند، که می گفتند: "The big O and it's all about the O".

انتقال Overstock.com از بسته ERP خود شرکت به بسته اینترنتی اوراکلی که برای پیاده سازی و اجرا و اتمام آن تا قبل از تعطیلات سال نو 2005 عجله زیادی شد، این شرکت را از پاسخگوی به مشتریان در خصوص وضعیت سفارشات و تحویل سفارشات ناتوان گذاشت. در نتیجه سیستم پیگیری مشتری به مدت یک هفته خوابیده بود. که این یک نتیجه شوک آور برای شرکتی است که ادعای رقابت با شرکت آمازون را دارد. آیا overstock.com نجات خواهد یافت؟

وبسایت مالی Motley Fool، این شرکت را یکی از بزرگترین سهام سقوط یافته نامید. ( هر چند که این شرکت امروزه در وضعیت مساعدی می باشد.)

خلاصه مشخصات پروژه

نام پروژه: overstock.com

اهداف پروژه

رقابت با شرکت های e-commerce، Amazon و E-bay

نتيجه اجراي پروژه

از دست دادن 14.2 میلیون دلاری سرمایه

علت شکست

پیاده سازی سیستم ERP جدید

درس هاي گرفته شده از پروژه

بر طبق صحبت های مدیرعامل این شرکت: "این شکست تقصیر من بود، من مدت زیادی جهت ارتقا سیستم های it اقدام خاصی انجام ندادم و در زمان ارتقا و اجرای سیستم جدید فشار زیادی را برای سریعتر انجام شدن آن وارد آوردم"، می توان از این عوامل درس گرفت.

 

منبع:

· http://www.lessons-from-history.com/Presentations/Articles/Overstock.com%27s%20Four-Year%20ERP%20Nightmare.pdf

 

 

تصویر اسدالله ميرزايي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط اسدالله ميرزايي - دوشنبه، 27 بهمن 1393، 09:55 ق.ظ
  سیستم رایانه ای ارسال آمبولانس لندن:
(London Ambulance Service)
هدف اصلی پروژه، استقرار یک سیستم تقریبا خودکار جامع بود. با ورود این سیستم، نقش جدید اپراتورهای بخش مرکزی کنترل آمبولانس، دریافت پیام های ورودی و ثبت جزئیات آنها در سیستم می شد. تنها در پیچیده ترین حالتها برای تخصیص بهترین منبع ، به مداخله انسان نیاز می شد، بنابراین سیستم ارسال رایانه ای، فرامین و کنترل های زیر را به طور خودکار انجام می داد: 
 ردیابی خودکار وسایل نقلیه؛
 شناسایی و تخصیص خودکار منابع؛ 
 شناسایی خودکار تلفن های تکراری؛ 
 مدیریت منابع، عمدتاً موقعیت یابی وسایل نقلیه برای به حداقل رساندن زمان پاسخگویی؛
 نگاشت رایانه ای (موقعیت ) با شناسایی باجه تلفن عمومی.
 LAS قصد داشت از روش مدیریت پروژه PRINCE استفاده کند، ولی هیچکس در LAS تجربه به کارگیری این روش را نداشت. از این رو برای رفع این مشکل، یک دوره آموزشی کوتاه مدت PRINCE برای گروه پروژه گذاشته شد. با توجه به حجم کار، این عمل متاسفانه نامناسب به نظر رسید وبرای پروژه زیان بار تشخیص داده شد.
این موضوعات، اثر قابل ملاحظه ای بر موفقیت پروژه می گذاشتند.
 از طرف LAS هیچ فردی به طور تمام وقت در پروژه کار نمی کند. 
 نبود توضیح رسمی در رابطه با نحوه اعمال روش PRINCE .
 نبود برنامه ای رسمی برای جلسات گروه پروژه و سایر جلسات. 
 نگرانی در مورد انتخاب متهورانه بازه های زمانی برای پروژه؛ شش ماه، در مقایسه با متوسط صنعت (18 ماه ) برای این نوع پروژه بسیار کوتاه بود.
 در برنامه تأمین کننده، هیچ زمانی برای بازنگری و تجدید نظر گنجانده نشده بود. هر چند این موضوعات در مراحل اولیه پروژه مطرح گردیده بود، ولی هیچ مدرکی وجود ندارد که آنها پیگیری شده یا به اطلاع مدیریت ارشد رسانده شده باشند. 
 علل شکست پروژه LAS 
 فشار زمان بندی
 سودای رهبری
مدیریت ریسک نامناسب
تضمین کیفیت نا مناسب 
مدیریت پروژه نامناسب
عدم مدیریت صحیح پروژه و نبود تجربه در گروه، عامل اصلی شکست در شناسایی و تشخیص اهمیت مشکلات بسیاری بود که درنهایت، چنین اثر تأسف آوری را بر نتیجه پروژه گذاشت و پروژه با شکست مواجه شد.
تصویر سيدروح الله احمدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سيدروح الله احمدي - چهار شنبه، 29 بهمن 1393، 03:31 ب.ظ
 

نیاز سنجی

اصولا زمانی که سازمانهایی که کسب وکارشان از طریق انجام پروژه هاست، رشد کرده و تعداد و پیچیدگی پروژه ها افزایش پیدا می کند، بهترین روش مدیریت کارآمد وبهره ور پروژه ها، مدیریت از طریق "پیاده سازی دفتر مدیریت پروژه" است. در موارد زیر این اهمیت بروز و نمود بیشتری خواهد داشت:

  • - زمانی که سازمان پروژه های متعدد دارد ولی به اندازه تعداد پروژه ها مدیران پروژه توانمند ندارد
  • - زمانی که پروژه ها بر اساس سیاستها ودستورالعملهای یکپارچه ومدون اجرا نمیشود وهر مدیر پروژه ای بر اساس سلیقه ودانش وتجربه خودش روال هایی رو در پروژه جاری می کند یا بر اساس سطح دانش وتجربه کارفرمای پروژه ونظارت پروژه روال هایی به پروژه تحمیل میشود که لزوما ممکن است مناسب این پروژه نبوده و یا به نفع پیمانکار نباشد ولذا چون سازمان از سطح بلوغ مناسب در تدوین زیر ساختهای فرآیندی برخوردار نیست مجبور خواهد بود به این مساله تمکین نماید ولی با ایجاد دفتر مدیریت پروژه که قادر به چانه زنی فنی در مورد موارد اختلافی خواهد بود، به مرور این موارد حل می شود.
  • - زمانیکه با افزایش تعداد پروژه ها ،سازمان با مشکل تخصیص منابع مختلف تو پروژه ها مواجه می شود. حالا این منابع از ماشین آلات ونیروی انسانی گرفته تا متریال ومنابع پولی و غیره مدیریت نخواهد شد مگر از طریق یک سازمان واحد که همان دفتر مدیریت پروژه است که البته این کار هم به نظرنگارنده جز سخت ترین کارهای دفتر مدیریت پروژه است که باید انجام شود که انجام درست آن در موفقیت پروژها نقش مهمی ایفا خواهد کرد
  • - زمانی که سازمان درگردآوری مستندات وگزارشها در پروژه های مختلف دچار مشکل است، بهترین راه حل "مدیریت اسناد" ازطریق دفتر مدیریت پروژه است یکی از خروجی های مهم پروژه همین مستندات ونقشه ها وگزارشهاست که اگر درست نگهداری، توزیع و بایگانی نشود گاهی می تواند ضررهای بزرگی به پروژه زده ومشکلات بزرگی برای سازمان بوجود بیاورد در حالی که اگر این مستندات از طریق سازمانی واحد، مانند دفتر مدیریت پروژه در پروژه های مختلف مدیریت شود می تواند مسائلی از این دست را قبل از وقوع سازماندهی و مدیریت نماید.


برآورد میزان ضرورت راه اندازی دفتر مدیریت پروژه: پرسشنامه خود ارزیابی سازمان:

انتخاب 6 مورد یا بیشتر: ایجاد دفتر مدیریت پروژه قویا توصیه می شود

انتخاب 10 مورد یا بیشتر: ایجاد دفتر مدیریت پروژه ضروری است


1. نرخ شکست پروژه ها بسیار بالا است

2. متدولوژی مدیریت پروژه به صورت گسترده پذیرفته و بکار گرفته نشده است

3. درخواستهای تغییر محدوده خارج از کنترل پروژه هستند

4. یک استخر منابع مشترک برای چندین پروژه در نظر گرفته شده است

5. کمبود تخصصهای مدیریت پروژه در حوزه های مورد نیاز وجود دارد

6. چندین تامین کننده کالا و خدمات بطور مشترک در پروژه ها استفاده می شود

7. نیاز مبرمی برای یکپارچه کردن گزارشها و معیارها وجود دارد

8. زمان تحویل محصول یک عامل کلیدی موفقیت محسوب می شود

9. هزینه های کلی و بالاسری پروژه بسیار بالا است

10. استخر منابع سازمان با نیازمندی های تخصیص منابع در پروژه ها همخوانی ندارد

11. آموزشها در بهبود عملکرد پروژه موثر نیست

12. برنامه جذب نیروی انسانی پروژه اثربخش نیست

13. بهره گیری از بهترین عملکردها با مشکل مواجه است

14. کنترلی بر سبد پروژه وجود ندارد

15. هیچ هماهنگی در ارائه گزارش های وضعیت پروژه و گزارشهای تحلیلی وجود ندارد

16. تداخلهای زیادی در زمان بندی منابع وجود ندارد

17. فاصله قابل توجهی بین بلوغ فرایندهای مستند شده و بلوغ اجرای آنها وجود ندارد. [۱]

تصویر سيدروح الله احمدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سيدروح الله احمدي - چهار شنبه، 29 بهمن 1393، 03:46 ب.ظ
  چند پروژه كه با تصميمات غير كارشناسي كليد خورد و به علت ضعف نياز سنجي با شكست روبرو شد

مدیرعامل شرکت زیرساخت اعلام کرد 
محمود خسروی خبر برچیده شدن V.P.n بومی را در گفتگو با شبکه ۲ صدا و سیما اعلام کرد. او گفت ماه پایانی سال قبل از سوی [شورای عالی] فضای مجازی به شرکت زیرساخت گفته شد که وی‌پی‌ان باید بسته شود و این شرکت ظرف ۱ ماه این کار را انجام داد. 
وی ادامه داد از ما خواسته شد تا زیرساخت وی‌پی‌ان را به صورت قانونی در اختیار شرکت‌ها و مردم قرار دهد، اما علیرغم تمام تبلیغاتی که صورت گرفت و میلیاردها تومان برای این پروژه هزینه شد، استقبالی از این طرح نشد و فقط ۲۶ شرکت برای وی‌پی‌ان قانونی ثبت نام کردند. 
خسروی اعلام کرد بسیاری از شرکت‌های خصوصی، سفارتخانه‌ها و بخش‌های خصوصی اصلا نیامده‌اند تا از این مسیر استفاده کنند و ما می‌بینیم که عوارض زیادی به وجود آورده‌اند و این معضل هنوز وجود دارد و نمی‌دانیم بسیاری از این مشکلاتی که برای مشتریان به وجود آمده چگونه می‌شود حل کرد.
تصویر سيدروح الله احمدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سيدروح الله احمدي - چهار شنبه، 29 بهمن 1393، 03:47 ب.ظ
 

جست‌وجوگر ملی ناتمام ماند



ابتدا قرار بود نامش را "یاحق" بگذارند و وظیفه‌اش ارائه خدمات دستگاه‌های دولتی و غیردولتی با هدف تسهیل در ارائه اطلاعات سریع به مردم در نظر گرفته شده بود. اما یک سال هم نگذشته بود که این موتور جست‌وجو به خاطره‌ها پیوست و ظاهرا وزارت ارتباطات سیاست‌هایش را تغییر داد چراکه معتقد بود باید نسبت به ارتقای موتورهای جست‌وجوگر داخلی اقدام شود و تمرکز تنها برروی یک موتور جست‌وجو قرار نگیرد.
همه چیز زمانی آغاز شد که رضا تقی‌پور - وزیر پیشین ارتباطات و فناوری اطلاعات - در سال 89 اعلام کرد که برای برطرف کردن نیازهای بومی در حال کار برروی یک موتور جست‌وجوی ملی هستیم.

البته کارشناسان خارجی که فعالیتشان در حوزه طراحی موتورهای جست‌وجوی بین‌المللی مانند یاهو و بینگ است در این باره اعتقادی متفاوت دارند. مدیر پیشین بازاریابی شرکت یاهو در رابطه با راه‌اندازی موتورهای جست‌وجوی داخلی معتقد است: ساخت و کار کردن برروی یک موتور جست‌وجو بسیار سخت و گران است و در این زمینه باید از تکنیک‌های بسیار و محاسباتی استفاده کرد. در کنار این موضوع، موتورهای جست‌وجو بسیار هزینه‌بر هستند و درصورت سرمایه‌گذاری‌های کلان می‌توان در این زمینه پیشرفت کرد.
ماروین لیائو ادامه داد: ما در روسیه، چک و کره جنوبی موتورهای جست‌وجوی بسیار خوبی داریم البته این موتورها 10 سال است که فعالیت خود را آغاز کردند و ممکن است کمی برای شروع دیر باشد. در کل می‌توان گفت رسیدن به موفقیت در این زمینه بسیار سخت است و نیاز به پشتکار و سرمایه فراوان دارد.
اما علی حکیم جوادی - رییس پیشین سازمان فناوری اطلاعات - در پاسخ به سوالی که درباره سرنوشت و وضعیت فعلی موتور جست‌وجو و ای‌میل فخر و فجر مطرح شده بود، اظهار کرده بود: فخر و فجر در واقع فراخوانی برای شناسایی علاقه مندان همکاری در حوزه موتورهای جست‌وجو و پست‌های الکترونیکی بود تا علاقه‌مندان این بخش اعلام آمادگی کرده و با گرفتن مجوز‌های لازم به فعالیت بپردازند، لذا محصولی با این نام وجود نداشته است.
وی همچنین یادآور شده بود: در حال حاضر چندین موتور جست‌وجو در مراحل نهایی کار قرار دارند و در آینده‌ای نزدیک زمان بهره‌برداری از آن‌ها اعلام خواهد شد.
رییس سازمان فن‌آوری اطلاعات همچنین عنوان کرده بود: در زمینه‌ پست الکترونیکی هم مواردی وجود دارد اما به دلیل آنکه ما قول دادیم اسامی این موتورهای جست‌وجو و ای‌میل‌ها را اعلام نکنیم تا زمان بهره‌برداری نامی از این پروژه‌ها نخواهیم برد.
اما وی در پاسخ به زمان بهره‌برداری از این موتورهای جست‌وجو و ای‌میل‌ها اظهار کرد: تمام تلاش ما بر آن است که تا پایان سال 91 این موارد مورد بهره‌برداری قرار بگیرند.
رییس سازمان فن آوری اطلاعات ادامه داد: برخی از این پروژه‌ها از جمله برخی موتورهای جست‌وجو هم آماده هستند، اما به دلیل حساسیت‌هایی که در این بخش وجود دارد اگر این جست‌وجوگرها از کیفیت لازم برخوردار نباشند ممکن است بعدها آن طور که شایسته است توسط مردم مورد استفاده قرار نگیرند، به همین دلیل لازم است روند بهره‌برداری از این جست‌وجوگر‌ها با دقت کافی صورت بگیرد.
اما در کنار تمامی این عوامل وقتی در سایت "الکسا" در بخش کشور ایران رتبه موتورهای جست‌وجو را مقایسه می‌کنیم رتبه اول باز هم به گوگل اختصاص پیدا کرده است.
برای مثال هنگامی که رتبه سایت پارسی‌جو در بین سایر سایت‌های ایرانی را جستجو می‌کنید، متوجه خواهید شد که این درگاه در بین سایت‌های ایرانی رتبه 665 را به خود اختصاص داده است. رتبه رقیب این موتور جستجوی ملی یعنی پارسی‌یاب در بین سایت‌های ایرانی 891 است که برای یک سایت جستجو مناسب نیست. شاید بهتر باشد هزینه‌ای که در این بخش درحال سرمایه‌گذاری است در مواردی با اهمیت بیشتر هزینه شود.

اما هدف مهمی که از آغاز موجب مطرح شدن جست‌وجوگر ملی شد، ایجاد امکان برای جست‌وجوی اطلاعات ایرانیان در پایگاه و بی‌نیازی به موتورهای جست‌وجوی جهانی با رفع نیاز داخلی است. اما به راستی این موتورهای جستجوی داخلی تاکنون چقدر توانسته‌اند نیازهای مردم را برطرف کنند؟


تصویر سيدروح الله احمدي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سيدروح الله احمدي - چهار شنبه، 29 بهمن 1393، 03:45 ب.ظ
 

400 میلیون تومان خرج کپی مرورگر ملی


مهرماه سال 92 خبر طراحی و آغاز به کار مرورگر
 
ملی ساینا با همکاری مرکز متما و شرکت ایمن رایانه امیرکبیر و مپنا به سفارش سازمان فناوری اطلاعات ایران منتشر شد و با گذشت چند ماه از انتشار این خبر حرف و حدیث‌ها درباره کپی بودن این مرورگر با پسوند پر طمطراق “ملی” در رسانه ها پیچید. با وجود انتشار گزارش هایی فنی و ارایه جزییات در خصوص کپی از فایرفاکس بودن این مرورگر که با بودجه 400 میلیونی طراحی شده است اما تاکنون متولیان دولتی توضیحی در این خصوص منتشر نکرده‌اند و تلاش های خبرنگار فناوران برای دریافت توضیح از سازمان فناوری اطلاعات ایران نیز به جایی نرسید.
فناوران - در آخرین خبر منتشر شده در این خصوص، خبر‌گزاری دانشجو اطلاعاتی به نقل از یک منبع آگاه منتشر کرد. این فرد که مصر است هویت‌اش فاش نشود با بیان اینکه کپی‌برداری مرورگر ملی ساینا از فایرفاکس مورد جدیدی نیست که نیاز به کشف داشته باشد، این نسخه‌برداری را ناشی از «رعایت قوانین» بین‌المللی دانسته است.
این فرد مطلع در مرکز مدیریت توسعه ملی اینترنت (متما) در مورد برخی ابهامات در خصوص کپی بودن مرورگر ساینا از روی فایرفاکس گفت: دیدن برخی کلمات مربوط به فایرفاکس موضوع مخفی نبود که عده‌ای بخواهند آن را کشف کنند چرا که یک مرورگر ترکیبی از چند جنبه مختلف است که توسعه هر یک از این جنبه‌ها (از صفر تا صد) بدون شک به منابع زیادی از جمله ده‌ها و بعضا صدها نفر- سال نیروی انسانی نیاز دارد بنابراین باید نقشه‌ راهی طولانی تدوین شود و به عنوان نخستین گام از این نقشه‌راه باید یک مرورگر بومی‌سازی شده اجرایی شود که بتوان با دریافت بازخوردهای کاربران، نیازهای دقیق‌تر را شناسایی و جوانب کار را دقیقا سنجید و در ادامه یک مرورگر ایرانی را ایجاد کرد. 
این فرد که نخواست نامش فاش شود در خصوص اینکه چرا در فایل‌های مرورگر ساینا کلمه موزیلا به چشم می‌خورد گفت: از آنجا که در تولید این محصول از محصولات متن‌باز موزیلا نیز استفاده شده است و محصولات با مجوز MPL اجازه تغییر این نام را ندارند از این رو برای اخذ این مجوز عدول از این قوانین امکان پذیر نیست و در این راستا نیز ساینا تلاش کرده است علاوه بر قوانین داخلی به قوانین بین‌المللی هم پایبند باشد.

این منبع آگاه با بیان اینکه این مرورگر در حال حاضر حدود نیم میلیون کاربر دارد، گفت: اینکه گفته می‌شود در مرحله اول اجرای این طرح حدود 400 میلیون تومان صرف شده و در مرحله توسعه آتی و اصلاح و تغییرات ساختاری به 500 میلیون تا یک میلیارد تومان بودجه نیاز دارد باید گفته شود که ما تنها اعلام کردیم که اگر این مقدار بودجه باشد خوب است و تاکنون هزینه‌ای به این میزان دریافت نشده است.
گفتنی است دهم مهرماه سال 92 محمد‌رضا توکلی، سرپرست مرکز مدیریت توسعه ملی اینترنت از طراحی و آغاز به‌کار نخستین مرورگر ایرانی با عنوان ساینا خبر داد. اجرای این طرح با همکاری مرکز مدیریت توسعه ملی اینترنت (متما) و شرکت ایمن رایانه امیرکبیر و مپنا به سفارش سازمان فناوری اطلاعات ایران انجام شد.

پس از گذشت 3 ماه از ورود مرورگر ایرانی ساینا ابهاماتی در خصوص کپی یا بومی بودن این مرورگر مطرح شد و عده‌ای با قطعیت کامل عنوان کردند که مرورگر ساینا مرورگری کپی شده از فایرفاکس است و این مرورگر قابلیت ویژه‌ای ندارد.
این عده برای ثابت کردن ادعای خود به مواردی نیز استناد کردند و معتقد بودند از لوگو تا تمام مراحل نصب و راه‌اندازی مرورگر ساینا دقیقا کپی برداری از روی فایرفاکس است و از نظر تست امنیتی و سرعت هم رده با کروم و فایرفاکس قرار دارد و حتی در مورد تست «HTML5» نیز دقیقا هم امتیاز با گوگل کروم قرار دارد که همین موضوع برای مرورگری که هنوز مراحل توسعه خود را طی نکرده است بعید به نظر می‌رسد.مخالفان ساینا این مرورگر را صرفا یک ورژن شخصی سازی شده از مرورگرفایرفاکس عنوان و تاکید کردند با یک بررسی ابتدایی و کلیک روی فایل اجرایی saina.exe خواهیم دید که حتی هنوز کپی رایت این مرورگر با جمله «تمام حقوق برای مرورگر فایرفاکس محفوظ است» به چشم می‌خورد.
تصویر نرگس گودرزي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط نرگس گودرزي - يکشنبه، 10 اسفند 1393، 12:48 ق.ظ
 

سلام علیکم

هر پروژه اگر خلاقیت و پشت کار و پشت بانه مالی نداشته باشد حتما شکست خواهد خورد . اگر نگاهی سطحی به شرکت تولید نی شکر در ایران داشته باشیم با گفتن اینکه این مکان قدیمی است و  بیش از تولیدش دارد مصرف می کند با  این سیاست غلط هزاران نفر بیکار و تولید نی شکر به صفر رسید تا انجا که باید واردات داشته باشیم و این نگاهی کوچک بود اما در سطح وسیعتر چه؟

تصویر ندا همتي نژاد
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط ندا همتي نژاد - جمعه، 15 اسفند 1393، 11:52 ق.ظ
 

پس از سپری شدن دو سال از معرفی عینک گران‌قیمت شرکت گوگل، کارشناسان معتقدند که این پروژه هیچ وقت به موفقیت پیش‌بینی شده نرسیده است.

به گزارش سرویس علمی ایسنا منطقه خراسان، کارشناسان معتقدند که با توجه به قیمت بسیار بالای 1500 دلاری و برخی از تبلیغات اغراق آمیز در مورد کارایی‌های این عینک، بیشتر کاربران استفاده از عینک را محدود کرده و اغلب از کارایی آن ناراضی هستند.

یکی از دلایل موثر در کمرنگ شدن موفقیت عینک گوگل، کافی نبودن برنامه‌های ارتباطی آن با گوشی‌های هوشمند است، به طوری‌که تاکنون تنها در حدود 100 برنامه کاربردی برای این عینک موجود است که اغلب از رابط کاربری ضعیفی برخوردارند.

به گفته تام فرانکل، مدیر اجرایی شرکت گای‌گیم، اگر طبق ادعای گوگل تاکنون 200 میلیون عینک به فروش رفته باشد نباید شاهد ترک مدیران بخش طراحی و ساخت پروژه عینک گوگل باشیم.

کریس نیل، مدیر پروژه عینک گوگل با اشاره به زمان‌بر بودن روند محبوب شدن پروژه‌های غیرعادی نظیر عینک گوگل افزود: پروژه عینک گوگل تنها یکی از دستاوردهای آزمایشگاه گوگل ایکس است. وظیفه این بخش تولید و تجاری کردن پروژه‌های آینده‌نگر گوگل نظیر خودروی خودران هوشمند و ابزارهای پوشیدنی است.

کارشناسان ابر صنعت IT معتقدند با توجه به وعده‌های شرکت گوگل بر عمومی‌سازی پروژه عینک گوگل در سال 2015 و رضایت کم کاربران از نسخه آزمایشی احتمال موفقیت این پروژه کم است.

 

تحقيقات اخير نشان داده است كه حدود 62 درصد پروژه‌هاي IT در زمان تعيين شده و يا با هزينه پيش‌بيني شده نتوانسته‌اند به انجام برسند.
در واقع بسياري از پروژه‌هاي IT قبل از اتمام، لغو شده و يا اصلاً پياده‌سازي نشده‌اند.

طبق آمار ماه آگوست 2007 ، از اين ميان، 49 درصد پروژه‌ها دچار مشكل افزايش بودجه لازم، 47 درصد دچار مشكل هزينه‌هاي نگهداري پيش‌بيني نشده و 41 درصد دچار مشكل عدم جوابگويي نيازها شده‌اند.
دليل عمده شكست اين پروژه‌ها مربوط به مديريت پروژه (Project Management) مي‌باشد
.

به طور كلي پروژه‌هاي IT بر اساس موفقيت به سه طبقه كلي تقسيم مي‌شوند:
• Successful Projects : 
پروژه‌هايي كه به موقع و با هزينه تعيين شده و نيز با كليه ويژگي‌هاي تعريف شده به پايان رسيده‌اند.
• Failed Projects : 
پروژه‌هايي كه لغو شده و يا به مرحله پياده‌سازي نرسيده‌اند.
• Challenged Projects : 
پروژه‌هايي كه با هزينه و يا زمان بيشتر و يا قابليت‌هاي كمتري،انجام و به بهره‌برداري رسيده‌اند.


تيم پروژه، مشتريان پروژه و ديگر افراد درگير در آن مي‌توانند از دلايل شكست يك پروژه IT باشند، اما دليل عمده شكست پروژه به مديريت پروژه و نيز فرهنگ‌هاي سازماني برمي‌گردد.

دلايل شكست اين پروژه از ديد بنده :1- قیمت بسیار بالای 1500 دلاری و 2-کافی نبودن برنامه‌های ارتباطی آن با گوشی‌های هوشمند است، به طوری‌که تاکنون تنها در حدود 100 برنامه کاربردی برای این عینک موجود است که اغلب از رابط کاربری ضعیفی برخوردارند.و اين موارد نشان دهنده عدم نيازسنجي درست مهندسان اين پروژه است.

به طور كلي دلايل اصلي شكست پروژه‌هاي IT عبارتند از :

Poor Planning (طرح ريزي ضعيف)

) Unclear Goals and Objectives اهداف و مقاصد غيرشفاف و نامشخص)

) Objective Changes during Projects تغييرات اهداف پروژه در حين انجام آن)

) Unrealistic Time or Resource Estimate پيش‌بيني غيرواقعي زمان و يا منابع پروژه)

) Lack of Executive Support and User Involvement نقصان پشتيباني اجرايي و درگير نمودن كاربران در پروژه )

) Failure to Communicate and Act as a Team شكست در ايجاد ارتباط مدير پروژه با تيم پروژه)

) Inappropriate Skills تجربه‌هاي ناكافي و غيرمقتضي تيم پروژه)

Lack of Testing and QA(Quality Assurance) standards (نقصان استانداردهاي تست و تضمين كيفيت)

) Users and Organizations Resistances مقاومت‌هاي كاربران و سازمان‌ها در پذيرش سيستم‌هاي جديد)

نتيجه‌گيري:
مديران پروژه مي‌توانند با رعايت توصيه‌هاي زير احتمال شكست پروژه‌ها را كاهش دهند:
• 
توجه به موارد بحراني موجود در پروژه و نيز مديريت تغييرات (Changes Management)
• 
انجام فرآيندهاي لازم جهت برخورد با ريسك‌هاي موجود در پروژه
• 
مشخص ساختن اهداف پروژه به صورت شفاف
• 
عدم استفاده از تخمين خطي در پيش‌بيني زمان و منابع پروژه
• 
پشتيباني گرفتن از مديريت اجرايي پروژه و ارتباط مستمر با تيم پروژه
• 
كسب اطمينان از وجود تجارب طرح‌ريزي و استفاده از تكنولوژي‌هاي و راه حل‌هاي مناسب
• 
ايجاد پروسه تست و تضمين كيفيت پروژه‌ها(Projects Quality Assurance)

تصویر فاطمه رضايي ادرياني
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط فاطمه رضايي ادرياني - دوشنبه، 11 خرداد 1394، 09:19 ق.ظ
  بطور کلی دلایل اصلی شکست پروژههای ITدر ایران را می توان به دو دسته ی عوامل داخلی و خارجی تقسیم کرد:


عوامل داخلی:
-مدیران پروژه کم تجربه
-ناتوانیهای شرکتهای تولید نرم افزار
-قراردادهای ناپخته
-کمبود نیروی انسانی متخصص
-مقاومت های کاربران و سازمانها در پذیرش سیستم های جدید
-ارتباط با مشتریان و کاربران و عدم درگیر نمودن کاربران در پروژه

عوامل خارجی:
-نبود سرمایه گذاری مناسب برای پژوهش و تحقیق در حوزه نرم افزار
-سرمایه گذاری کم در بخش خصوصی و عدم حمایت دولت
-عدم استفاده از یک استاندارد واحد
-مشکلات حضور در مناقصات بین المللی
-ارزان بودن نرم افزار و عدم در نظر گرفتن ان بصورت یک کالا
-ما ه های سال، تعطیلات رسمی و برنامه ریزی زمانی 
-ا دغام شوراها
-عدم شناسایی حقوق مولفین وقانون کپی رایت
- تحریم ایران
-مشکلات موجود کشور در زمینه مستندسازی تولید محصولات نرم و رعایت نکردن مستندات تعریف شده نرم افزاری
تصویر فاطمه رضايي ادرياني
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط فاطمه رضايي ادرياني - دوشنبه، 11 خرداد 1394، 09:21 ق.ظ
  شکست پروزه VPN
پروژه ملی ساماندهی VPN یا قانونی‌سازی آن که گویا طبق گفته‌های مدیر عامل زیرساخت با شکست مواجه شده و آثار زیان‌باری را برای مشترکان داشته است و نحوه جبران این خسارت‌ها هنوز مشخص نیست، اقدامی در راستای یکپارچه‌سازی بسترهای خارجی ارتباطات اینترنتی بود.

با توجه به اینکه فعالیت در بخش تولید نرم‌افزارهای فیلترشکن نیاز به علم نرم‌افزاری دارد و فعالان خلاق در این حوزه به راحتی می‌توانند از پس این کار برآیند، نظارت بر آن بسیار مشکل است و حتی اگر برخورد سلبی با این موضوع صورت گیرد و درگاه‌های ارتباطی VPN بسته شود، باز هم برای خلاقان راه‌های گریز بسیاری وجود دارد.

محسن امیری با اشاره به اینکه در قانون جرائم رایانه‌ای نیز به این موضوع اشاره و در بند اول دسترسی‌های غیرمجاز آن قید شده " هر کس به طور غیر مجاز به داده‌ها یا سامانه‌های رایانه‌ای یا مخابراتی که به وسیله تدابیر امنیتی حفاظت شده است دسترسی یابد، به حبس از ۹۱ روز تا یک سال یا جزای نقدی از پنج میلیون ریال تا بیست میلیون ریال یا هر دو مجازات محکوم خواهد شد"، اما باز هم تا اختلالی در کار مشترکان ایجاد و شکایتی صورت نگیرد، قانون به سراغ خاطیان نمی‌رود.

وی گفت: سبب این موضوع هم مشخص است؛ اطلاعات درست و کاملی از فروشندگان و تولیدکنندگان پورت‌های VPN در دست نیست زیرا تمامی آن‌ها از سرورهای خارجی و رجیسترهای خارج از مرز استفاده می‌کنند و با اشتراکی که به مشترکان می‌فروشند، حق استفاده را برای آن‌ها به وجود می‌آورند.

او ادامه داد: موضوع VPN قانونی هم که در راستای نظارت بیشتر بر این حوزه مطرح شده، به دنبال این بود که فضای گسترده اینترنت را زیر بال و پر خود بیاورد در حالیکه عملا این کار نشدنی به نظر می‌رسد.

این کارشناس فضای مجازی با اشاره به اینکه تولید درگاه‌ها و پورت‌های تازه، چندان کار سختی نیست، عنوان کرد: قانون درصدد بود تا با ارائه خدمات قانونی و قابل رصد، مبارزه‌ای سرسختانه با فعالیت‌های غیر قانونی داشته باشد و پورت‌های مسیردهنده غیرقانونی را به محض تولید، مسدود کند.

اما تمامی این موضوعات در حالی مطرح است که بازخورد عملی اجرای این طرح نیز با شکست مواجه شده چرا که تعداد ثبت‌نام کنندگان حقوقی در حدود ۲۰ تا ۳۰ شرکت بوده‌اند و عملا سرمایه میلیاردی زیرساخت دور ریز شده است.

درگاه ثبت‌نام این خدمت که حدود یک ماه و نیم پیش آماده ثبت‌نام از کاربران حقیقی بود، به یکباره از دسترس خارج شد و خسروی –مدیر عامل زیرساخت- هم که خبر از آمادگی این شرکت برای خدمت‌رسانی به این قشر داده بود بعد از چند روز مطرح کرد: از سوی فضای مجازی از شرکت ما خواسته شد تا زیرساخت vpnرا به صورت قانونی در اختیار شرکت‌ها و مردم قرار دهد اما علی‌رغم تمام تبلیغاتی که صورت گرفت و میلیادرها تومان برای این پروژه هزینه شد، استقبالی از این طرح نشد و فقط ۲۶ شرکت برای vpn قانونی ثبت نام کردند.

او ادامه داد: بسیاری از شرکت‌های خصوصی، سفارتخانه‌ها و بخش‌های خصوصی اصلاً نیامده‌اند تا از این مسیر استفاده کنند و می‌بینیم که عوارض بسیاری به وجود آورده‌اند و این معضل هنوز وجود دارد و نمی‌دانیم بسیاری از این مشکلاتی که برای مشتریان به وجود آمده را چگونه می‌شود حل کرد.

امیری در انتها یادآور شد: برای نظامند کردن این بخش، بهتر است که قانون واحدی در بخش جرائم رایانه‌ای داشته باشیم و پایبند به آن عمل کنیم و پلیس سایبری‌ها را مسئول اجرایی قرار دهیم چرا که اگر غیر از این باشد، هر روز باید به فکر تولیدات و ساخت محصولات نوینی باشیم که در مقابله با راهکارهای مجرمانه اندیشیده می‌شود و این با توجه به گستردگی فضای مجازی، امری بیهوده است.
تصویر استاد- آقاي دكتر سيد محمدرضا ناصرزاده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط استاد- آقاي دكتر سيد محمدرضا ناصرزاده - پنج شنبه، 14 خرداد 1394، 08:31 ب.ظ
  با توجه به صحبت هایی که با یکی از دوستان فعال در زمینه فناوری اطلاعات و ارتباطات می کردم مطالبی هست که مشخصا باعث شکست برخی از پروژه های بزرگ نرم افزاری می شه

هر کدوم از موارد زیر که درست انجام نشن موجب شکست سنگین در پروژه می شن


***** نیاز سنجی:
این امر باید دقیقا توسط کارکنان سازمان بصورت کاملا حرفه ای و تجربی شناسایی بشه و بصورت کاملا سیستماتیک مستند بشه
نیاز هست که ترجمه این نیاز برای مجریان و پیمانکاران به صورت کاملا دقیق و جزئی باشه تا پیمانکاران بتونن دقیقا همون نیاز رو پیاده سازی کنن


***** امکان سنجی
اینکه نیاز درست شناسایی بشه بسیار بسیار مهمه اما اینکه آیا امکان سیستماتیک کردن و مکانیزه کردن کامل یک نیاز وجود داره یا خیر از اون مهم تره


***** هزینه سنجی
گاهی انجام سنتی یک فرآیند کوچک بسیار مقرون به صرفه تر از مکانیزه کردن اون هست و گاهی هم اتوماسیون فرآیند ها اونقدر در هزینه ها تاثیر گزار هست که تسریع و اولویت پروژه در دستور کار قرار می گیره


***** زمان بندی دقیق
با توجه به هزینه، درخواست، امکانات و شرایط موجود بایستی زمان پیش مطالعه و اجرای طرح کاملا مورد بررسی قرار گیرد تا کارفرما و پیمانکار زمان لازم و کافی را برای اجرای تعهدات خود داشته باشند
در صورتی که کارفرما زمان لازم و کافی را در جهت مطالعه کامل طرح توسط پیمانکار نداشته باشد طرح با شکست مواجه می شود و در صورتی که پیمانکار در زمان مشخص شده نتواند به تعهدات خویش عمل کند پروژه عملا شکست خورده است
زمان سنجی می بایست دقیق و منطقی باشد و اهرم های فشار کارفرما می تواند شکست های سنگینی را به پروژه تحمیل کند

***** انتخاب درست و دقیق مجری از دسته مهمترین موارد اجرایی هست
گاهی یک مجری هزینه کمی می گیره تا یک پروژه رو انجام بده غافل از اینکه این مجری بعلت تجربه کم یا غیر مرتبط در زمینه مورد درخواست پروژه رو با عدم مطالعه دقیق به شکست می کشونه
بنا بر این همیشه قیمت نباید فاکتور اصلی انتخاب پیمان کار باشه

***** تحلیل درست درخواست باید حتما توسط سه تیم حرفه ای و مسلط انجام بشه یک تیم از کارفرما یک تیم از پیمانکار و تیم سوم یک تیم حرفه ای از مهندسین صنایع و کامپیوتر هست که باید زبان مشترک کارفرما و پیمانکار رو بدونن و در صورت نیاز نظارت کامل رو بر کل پروژه داشته باشن

پس از انجام مراحل فوق نوبت به 
***** پیاده سازی، استقرار، اجرا، عملیاتی سازی ، تست، تغییر، ارتقاء، پشتیبانی، نگهداری، آموزش و .... می رسد

هر یک از مراحل فوق می بایست طبق استاندارد های موجود انجام شوند در غیر این صورت پروژه با شکست مواجه خواهد شد
تصویر حميده نام اورابادشاپوري
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط حميده نام اورابادشاپوري - جمعه، 15 خرداد 1394، 01:33 ب.ظ
  با سلام و احترام 

معرفی پروژه 1: 
نرم افزاری که مربوط به باز نویسی یکی از نمایندگی های تعمییرات سونی بود. اصل پروژه یک نرم افزار تحت داس بود که همه کارها در همان صفحه اصلی انجام می شد. وظیفه ما باز نویسی نرم افزار و طبق توافق با کافرما فروش آن به سایر نمایندگی ها بود. نرم افزار به اتمام رسید و این بار علی رغم تعامل و ارتباط موثری که با کارفرما داشتیم نرم افزار در آخر مورد استفاده قرار نگرفت.

بررسی شکست:
نرم افزاری که همه امورات آن در یک صفحه انجام می شد و خیلی ساده بود ، بصورت روندی و کارتابلی در آوردیم و قضیه پیچیده تر از آن شد که کاربران بتوانند از آن استفاده کنند.البته اشتباه در انتخاب پلت فرم و تحت وب کردن نرم افزار نیز زیاد بی تاثیر نبود. چون کاربران سالها از نرم افزار داس استفاده کرده بودند و به زبان ساده از محیط تحت وب نفرت داشتند.

معرفی پروژه 2 :
پروژه مربوط به بازنویسی نرم افزار تحت داس یکی از نمایندگی های شرکت هپکو بود . بعد از اتمام نرم افزار مورد استفاده قرار گرفت ولی 30 درصد نرم افزار را مجبور شدیم دوباره از اول بنویسیم و نهایتا پروژه دیر تحویل داده شد. البته این نرم افزار به مدت پنج سال است که بدون کوچکترین توقف و بدون پشتیبانی مورد استفاده قرار می گیرد.

بررسی شکست : 
برخی سناریوها و روند های موجود در نرم افزار را که گاها غلط و تکراری بودند را از اول طراحی کنیم . حق واقعا با ما بود و این سناریوها واقعا باید عوض می شدند اما چون بدون هماهنگی و تائید کارفرما بود و نیز چون به این روند ها عادت کرده بودند نتوانستیم آنها را قانع کنیم و مجبورا تغییرات را حذف کرده و چیزی شبیه به مدل خودشان ساختیم.

معرفی پروژه 3 : 
نرم افزاری که وظیفه اصلی آن صرفا آرشیو اسناد بود و در عین سادگی بسیار کاربردی و قوی بود ،و در بسیاری از مراکز دولتی استفاده می شد در نسخه دوم قرار شد نرم افزار را گسترش داده و ایده های جدیدی در آن اعمال کنیم.
نسخه دوم در مرحله کدنویسی متوقف شد. 

بررسی شکست :
شکست این پروژه چندین علت داشت اول اینکه هیچ کدام از ذینفعان پروژه دید مشترکی نسبت به نرم افزار نداشتند و اینکه هدف نرم افزار چه بود و بعد از اتمام نرم افزار قرار است چه کند از نگاه هر کسی چیزی متفاوت بود.و محدوه نرم افزار دقیقا مشخص نشد و اینها باعث شد در مرحله تحلیل اختلافات اساسی بین اعضای تیم بوجود آید . 
همچنین در پروژه بیش از دو مورد تکنولوژی جدید که برای برنامه نویسان نا آشنا بود به کار گرفته شد که ادامه کار را با مشکل مواجه کرد.
تصویر احمد اسمعيلي نوجه ده
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط احمد اسمعيلي نوجه ده - جمعه، 15 خرداد 1394، 08:42 ب.ظ
 

 

 

ده پروژه شکست خورده "Google" را بشناسید

 

google lively شکست خـورد ايـــده عالي، اجـــــرا فاجعه

 

گوگل زنده يا google lively نمونه جالبي از اصطلاح «ايده عالي، اجرا فاجعه» است و چه دليلي بهتر از اين که نه ما و نه شما هرگز اسمي هم از اين پروژه گوگل نشنيديم اگر چه براي شش ماه تمام در سال ۲۰۰۸ اجرا مي شد. اين پروژه وقتي اجرا شد که پروژه زندگي دوم يا second life و يا محيط هاي مجازي مشابه اداشتند کم رنگ و کم رنگ تر مي شدند. در شبکه اجتماعي گوگل زنده کاربران براي خود يک آواتار مي ساختند تا بتوانند در محيط سه بعدي با ديگران ارتباط برقرار کنند. در اين محيط مجازي که معماري مختص خودش را داشت افراد مي توانستند با هم دوست شوند و حرف بزنند و به جاهايي که دوست دارند سر بزنندافرادي که اين محيط را تجربه کرده بودند از مشکلات متعدد و اعصاب خرد کن سرور شاکي بودند ولي ايده اصلي به نظرشان جذاب بود. اتاق هاي چت تقريبا هم عمر خود اينترنت هستند و در آنها مي توان با آشنايان و غريبه ها حرف زد. با پيشرفت وب کم ها چت تصويري نيز تبديل به پيش فرض ما براي برقراري ارتباط با دوستان و آشنايانمان شده است. ولي چرا پروژه گوگل زنده و يا نمونه هاي مشابه آن نگرفت؟ اين روزها ما براي آشنايي با افراد غريبه از شبکه هاي اجتماعي استفاده مي کنيم و غريبه ها را از روي علايق مشترکي که داريم به دايره آشناهايمان راه مي دهيم. اغلب شبکه هاي اجتماعي پرکاربرد مانند فيس بوک، توييتر و يا شبکه هاي ايراني مانند ني ني سايت داشتن تجربه مشترک را پايه و اساس جمع کردن افراد دور هم قرار مي دهد.در شروع دنياي اينترنت جاهايي مانند زندگي دوم يا گوگل زنده قرار بود جايي باشند که ما گاهي به آنها سر مي زنيم. مثل سر زدن به شهربازي يا کافي شاپ در زندگي واقعي. ولي اينترنت خيلي فراتر از آن چيزي شد که در ابتدا تصور مي کرديم و امروزه ارتباط با غريبه ها کاري نيست که هر از گاهي انجام بدهيم بلکه جزو اصلي زندگي روزانه ما شده است.

 

google answers شـــکست خورد ‪جستجو کافي است. پاسخ لازم نيست

 

«گوگل پاسخ» پروژه ديگري است که اين روزها رها شده است. اصولا در دنيايي که جواب هر سوالي را با يک جستجوي ساده در گوگل مي توان پيدا کرد مفهوم «پاسخ» با آن چيزي که قبلا بود عوض شده است. اگر چه «ياهو پاسخ» هنوز وجود دارد و به کارش ادامه مي دهد ولي اين به خاطر اين نيست که او دارد واقعا پاسخي را به سوالها ارايه مي کند بلکه به اين دليل است که پاسخهايش عجيب و غريب و سرگرم کننده هستند.

 

وقتي شما به اطلاعات حقيقي احتياج داريد يا در گوگل جستجو مي کنيد و يا به وب سايتهاي تخصصي حوزه خود مي رويد و دنبال پاسخ خود مي گرديد بعضي وقتها هم از شبکه هاي اجتماعي خود استفاده مي کنيد و از دوستاني که مي شناسيد و به آنها اعتماد داريد سوال خود را مي پرسيد. دوباره مي بينيم که ايده اصلي تغيير ماهيت داد. اين که جايي باشد که کاملا جهاني است و پاسخ هر سوالي که هر کسي مي پرسد را دارد تبديل شد به يک نمونه شدني تر و انساني تر اما چطور مي شود که شرکتهاي زيادي روي ايده پاسخ دادن به همه سوالات ممکن سرمايه گذاري مي کنند؟ شرکتهايي مانند چاچا و يا askJeeves که ايده شان اين است که يک سوال درباره هر چيزي که مي خواهي بپرس و پاسخت را دريافت کن.

 

اما حقيقت اين است که آنها اصلا دنبال درست کردن چيزي مثل «گوگل پاسخ» نيستند بلکه کاري که مي کنند اين است که سوال شما را در گوگل جستجو مي کنند و نتيجه را به شما نشان مي دهند. استفاده از آنها مثل اين مي ماند که از شخص ديگري بخواهيد چيزي را در گوگل برايتان جستجو کند. براي اين که ايده «گوگل پاسخ» حتي بيشتر منجر به شکست بشود گوگل براي دريافت برخي از پاسخ ها با يک جور مدل مزايده اي به مترجمان آزاد پول مي داد. الان ناموفق بودن اين ايده بديهي است ولي مابين سالهاي ۲۰۰۲ تا ۲۰۰۶ که اين پروژه اجرا مي شد هنوز قابليتهاي عظيم اينترنت و حجم عظيم اطلاعاتي که بر روي آن يافت مي شود بر همگان مشخص نبود و گوگل خودش مي خواست اين خدمات را ارايه کند.

 

تبليغات چاپي و راديويي گوگل شکست خورد از اينتــــــرنت پول دربياور نه از بيرون آن!

جمله معروفي است که اين روزها شعار اغلب وب سايتها شده: از اينترنت پول در بياور. ولي چند سال قبل گوگل درست برعکس اين شعار حرکت کرد و تصميم گرفت از بيرون از اينترنت پول دربياورد. شايد تحت تاثير فشار روزافزون براي کسب درآمد بيشتر گوگل تصميم گرفت وارد صنعت تبليغات چاپي و راديويي شود. البته با اتکا به داده هاي بسيار زيادي که درباره کاربران و محصولات مورد علاقه شان داشت. البته اطلاعات شخصي مصرف کنندگان حکم قلک پر از طلايي است که گوگل دارد و در آينده پيش رو هم حتما از آن استفاده هاي زيادي خواهد کرد ولي با توجه به اين که اطلاعات هر روز بيشتر و بيشتر در دسترس همگان قرار مي گيرد استفاده از تبليغات براي پول درآوردن کماکان مهم ترين روش درآمدزايي است. استفاده از اطلاعات گوگل براي هدف قرار دادن مصرف کنندگان در بيرون از دنياي اينترنت ممکن است در تئوري بسيار جالب به نظر برسد ولي مشکل اين جا است که روشهاي قديمي براي برقراري ارتباط با مصرف کنندگان دارند از بين مي روند و عاقلانه نيست که گوگل در آن بازار سرمايه گذاري کند.

 

از طرف ديگر روشهايي که گوگل براي تعيين بهترين نقطه براي يک تبليغ اينترنتي دارد به همان خوبي در دنياي خارج جواب نمي دهد و مديران حوزه تبليغات راديويي و چاپي به مرور فهميدند تمايلشان به استفاده از روشهاي خودشان بيشتر از روشهاي به دست آمده از داده هاي گوگل است.

 

dodgeball شکسـت خورد ايــده پرداز قهـر کرد و رفت

 

در سال ۲۰۰۵ دو تا از پروژه هاي گوگل همزمان بيرون آمدند: آندرويد و داجبال (Dodgeball). بديهي است که اين جا لازم نيست از موفقيت آندرويد صحبت کنيم اما ماجراي داجبال جالب است. داجبال يک شبکه اجتماعي حساس به مکان بود و در سال ۲۰۰۵ شروع به کار کرد. اين محصول نيز ترکيبي است از نگاه به آينده و زندگي واقعي و تلاش براي ترکيب اين دو . اين اپليکيشن قرار بود از گوشي هاي هوشمند استفاده کند تا افراد را به هم وصل کند و مثلا جاهايي که يک نفر مي رود يا رستوران خوبي را که پيدا مي کند با کساني که مي شناسد و در منطقه هستند به اشتراک بگذارد.

 

خب چه بر سر اين ايده آمد؟ براي دو سال پروژه به خوبي پيش رفت تا اين که دنيس کراولي که ايده پرداز اوليه اين طرح بود در سال ۲۰۰۷ از گوگل بيرون آمد و شرکت فوراسکور را تاسيس کرد و اين شرکت که دقيقا همين خدمات را ارايه مي دهد الان بسيار محبوب است.

 

مشکل اين طرح در زمان خودش اين بود که زيادي آينده نگر بود و سخت افزار لازم براي فراگير شدن آن که همان گوشي هاي هوشمند بودند خيلي طول کشيد تا غالب بازار شود. امروزه گوگل latitude را دارد که همان کار را مي کند. البته اين خدمت آنلاين گوگل اصلا جذابيت فوراسکور را ندارد و شايد يک دليل آن قسمت بامزه بازي فوراسکور است که کاربران مي توانند ميزان علاقه و وفاداري خود را به يک کسب و کار و يا فروشگاه خاص نشان دهند. ولي از اين خصوصيات مهم تر اين است که استفاده از فوراسکور خيلي راحت تر از توييت کردن محلي که هستيم براي دوستانمان و يا انتشار آن در فيس بوک است. اين طرحي است که مي توانست از آن گوگل باشد و او با بي درايتي از دست داد.

 

جــــايکو شــــکست خــــورد توييتر قبلا اين ايده را پياده کرده بود

 

گوگل در سال ۲۰۰۷ يک سايت براي بلاگ هاي بسيار کوچک راه انداخت که جايکو نام داشت ولي تا سال ۲۰۰۹ معلوم شد که اين توييتر است که فاتح دنياي پستهاي کوتاه و سريع است. يک شبکه اجتماعي همان قدر قدرتمند است که کاربرانش قدرتمند باشند و توييتر در زماني که جايکو راه افتاد بيش از نصف راه موفقيتش را رفته بود. اگر چه هنگامي که جايکو از کار افتاد عده اي از کاربران سينه چاکش يک سيستم آرشيوي درست کردند تا تمام مکالمات خود را جايي ذخيره کنند و براي هميشه داشته باشند.

 

شايعات زيادي درباره دلايل دست شستن گوگل از جايکو وجود دارد ولي به هر حال اين پايان شروعي بود براي يک جور ميکروبلاگهاي کوچک که پستهاي اشخاص روي آن شکل هايکو همان شعرهاي معروف ژاپني را دارد.

 

google notebook شکست خورد احــــــتمالا ‪پيـــــچيده بـــود

 

گوگل نوت بوک در سال ۲۰۰۹ از مجموعه پروژه هاي گوگل کنار گذاشته شد.اگر چه گوگل داک کمابيش به آن سرويس داکيومنت اشتراکي که گوگل همواره دنبالش بود تبديل شده است شرکت گوگل هيچ گاه نتوانست در رقابتي که در اين حوزه وجود دارد از اپليکيشن هاي ديگر همچون evernote پيشي بگيرد. کپي کردن کليپهايي که آدرس اينترنتي شان را حفظ مي کنند به نظر يک امر بديهي مي رسد به خصوص اگر با مرورگر ترکيب شود. به همين دليل است که گوگل سالهاست دارد اين ايده را دنبال کند. اما باز هم وقتي همه تلاشها انجام مي شود و نوبت به آمار و ارقام مي رسد به نظر مي رسد کاربران سرويس هاي ديگر غير از گوگل را ترجيح مي دهند. معلوم نيست مشکل از پيچيدگي فراوان ابزارهاي گوگل است و يا رابط کاربري سرويس گوگل خوب نيست ولي دنياي ابزار نگارش در اختيار آن دسته از توسعه دهندگان است که ابزارهاي ساده و بسيار دم دستي توليد مي کنند. آن هم در حالي که پردازش ابري امکان ارسال نوشته ها را به خانه، محل کار و هر جاي ديگري به راحتي فراهم مي کند.

 

google Buzz شـــکســت خورد اعـــصاب کاربران را خرد کرده بود

 

خيلي از ايرانيان مرگ گوگل باز را به ياد دارند. کاربران ايراني شايد يکي از معدود گروه هايي بودند که عاشقانه گوگل باز را مي پرستيدند و از آن استفاده مي کردند ولي به هر حال گوگل مجبور شد آن را کنار بگذارد. اولين اشتباه گوگل باز اين بود که با کاربران صادق نبود. در فوريه سال ۲۰۱۰ اين خدمت گوگل به طور اتوماتيک به جي ميل اضافه شد و اضافه شدن دکمه باز در کنار اينباکس بدون هيچ گونه اطلاع رساني به مخاطبان صورت گرفت.

 

اما چه چيزي درون اين فولدر جديد بود؟ اين همان گوگل ريدر بود که يک تجربه بسيار موفق در زمان خودش بود. گوگل ريدر با استفاده از rss قابليتي ايجاد کرده بود که خوانندگان بتوانند سايتهاي محبوب خود را دنبال کنند. کار گوگل باعث شد که يک فولدر جديد به جي ميل افراد اضافه شود که هميشه در آن تعداد بسيار زيادي مطلب خوانده نشده وجود دارد و گوگل هيچ وقت نفهميد که اين فولدر اضافي چه بار سنگيني به مخاطبانش وارد مي کند. در سال ۲۰۱۱ گوگل پروژه باز را از ليست پروژه هايش کنار گذاشت.

 

sidewiki شــــکست خورد ‪ويکي پديا رقـابت ناپذير است

 

گذشته خيلي وقتها چندان شفاف نيست ولي اغلب ما آن دوران را به ياد داريم که هنوز ويکي پديا به وجود نيامده بود. چيزي که ويکي پديا را منحصر به فرد مي کند جامعه بزرگ و بسيار وفادار آن است که وقت خود را براي توسعه هر چه بهتر آن مي گذارند و برعکس آنچه بسياري از افراد مي گويند اين که هر کسي مي تواند مطالب آن را ويرايش کنند اصلا از اعتبار مطالب کم نمي کند.

 

اما همه اينها چه ربطي به گوگل دارد؟ سه پروژه searchwikiو knol و Sidewiki دليل اين مقدمه هستند.همه اضافات ويکي پديا و گزينه هايي که مي توانند جايگزين آن شوند از تابستان ۲۰۰۸ توسط گوگل توسعه داده شده است. knol پروژه توليد يک مجموعه از دست نوشته هاي کاربران است. searchwiki به کاربران اجازه مي دهد نتايج جستجو را رتبه بندي و امتياز دهي کنند و آخرين پروژه يعني sidewiki که روي مرورگر اضافه مي شود و اجازه مي دهد که وب سايتها را برچسب گذاري بکنيم. پروژه sidewikiعملا رها شده است و دو پروژه ديگر هم نتوانسته اند به موفقيت پيش بيني شده دست پيدا کنند.

 

همه کوشش ها براي توليد چيزي مانند ويکي پديا حتي آنهايي که توسط کاربران عاشق پيشه گوگل پشتيباني مي شدند نتوانستند به اندازه هاي بزرگي برسند و حتي پروژه knol در بهار سال ۲۰۱۲ به پشت ديوارها فرستاده شد. شايد اگر يک رابط کاربر متفاوت براي knol طراحي مي شد مي توانست هنوز مقاومت کند ولي مساله اين است که ويکي پديا خيلي قوي است و خدماتي که به کاربران در هر سطحي ارايه مي دهد بسيار مفيد هستند. از کاربران کاملا بي اطلاع نسبت به موضوع تا حرفه اي هاي هر حوزه آن را مي خوانند و مي توانند با آن ارتباط برقرار کنند و اين واقعا تعجب آور است. اگر خوب به فلسفه پشت آن بينديشيم مي بينيم اين که همه مي توانند به خانواده ويکي پديا بپيوندند چه براي استفاده از مطالب و چه براي توليد آنها و اين موضوعي استثنايي در تاريخ دنيا است.

 

در پروژه searchwiki مشکل اين بود که کاربران علاقه نداشتند تغييري در رتبه بندي گوگل ايجاد کنند به خاطر همين هم در سال ۲۰۱۰ اين پروژه با يک سيستم ستاره دهي جايگزين شد. در پروژه sidewiki کاربران هيچ وقت از کامنت هايي که در سايدبار وجود داشت استفاده نمي کردند و به همين خاطر هم گوگل اين پروژه را در سپتامبر ۲۰۱۱ رها کرد.

 

google video شکــــست خـورد مشکل با خريـــــد يوتيوب حل شد

 

گوگل ويدئو تلاش کرد تا يوتيوب را در هم بشکند و شکست خورد و تنها دليلش اين بود که اين ابزار قبلا وجود داشت و نامش هم يوتيوب بود. بعد از آن البته گوگل يوتيوب را با قيمت ۱.۶۵ ميليون دلار خريد و قال قضيه را کند و آخر سر همه خوشحال و راضي بودند. داستان گوگل ويديو تنها داستان يک حمله بي کله به يک کرگدن اينترنتي نبود. حقيقت امر خيلي عجيب تر از اين هاست. در ژانويه ۲۰۰۵ ريشه هاي چيزي که قرار بود گوگل ويديو شود در تبديل پخش تلويزيوني به متنهاي قابل جستجو شکل گرفت. در تابستان اين سال آنها شروع به پشتيباني از آپلودهاي ويديويي و به اشتراک گذاشتن آنها کردند و در انتهاي اولين سال شکل گيري آن، ايده اوليه تبديل گفتار تلويزيوني به متنهاي قابل جستجو کاملا از دست رفته بود. اگر چه در سال ۲۰۱۲ نمونه هايي از متن فيلمهاي ويديويي در يوتيوب ديده مي شود و نشان مي دهد که گوگل هنوز ايده اوليه را در سر دارد.

 

هر دليلي که باعث جذابيت و فراگيري سايتهايي مي شود که بر مبناي تجربيات کاربران طراحي مي شوند را در نظر بگيريد. گوگل ويديو کاملا بر خلاف آن حرکت کرد. آنها تصميم گرفتند يک نوع فايل اختصاصي با پلير مخصوص خودش را معرفي کند که به طرز چشم گيري مجموعه کارهايي که کاربر بايد انجام مي داد تا محتواي ويديويي خودش را داشته باشد زياد مي کرد. بعضي وقتها اين روش جواب مي دهد. بالاخره همه پليرها و انواع مختلف فايلهاي ويديويي از يک جايي آمده اند ديگر. ولي اين استراتژي براي وقتي که شما يک دعواي بزرگ را با سايت بسيار راحتي مانند يوتيوب شروع کرده ايد اصلا جواب نمي دهد. سايتي که محبوبيتش آن را تبديل به يک جور استاندارد در دنياي ويديو ها کرده استايده داشتن يک پلير و فرمت فايل اختصاصي در زماني که همه ابزار ها و نمايشگرها به دنبال پشتيباني هر چه بيشتر از فرمتهاي موجود مي روند يک جور خود کشي به حساب مي آيد.

 

بعد از اين که گوگل ويديو نتوانست با يوتيوب رقابت کند تصميم گرفت مدلش را عوض کند و تبديل به يک مرجع اجاره دادن ويديو ها شود و اين بار هم قبل از آن يک رقيب قدرتمند به نام نت فليکس در اين بازار بود که عينا همين سرويس را ارايه مي کرد و به خاط همين گوگل ويديو آن را هم رها کرد و در نهايت گوگل يوتيوب را خريد و به اين داستان خاتمه داد.

 

google wave شکــــــست خورد شايد آيندگان بپسندند، ما نپسنديديم

 

بزرگترين شکست گوگل را شايد بتوان گوگل موج (google wave) دانست. مجموعه اي از قابليتهاي بي فايده که با يک روش پيچيده و غير لازم دور هم جمع شده اندگوگل موج مي خواست براي همه، همه چيز در حوزه اشتراک محتوا باشد. همان طور که گوگل پلاس تلاش مي کند براي کاربران شبکه هاي اجتماعي همه چيز باشدهنوز معلوم نيست سرنوشت پلاس چه مي شود ولي مجلس ختم گوگل موج مدتهاست که برگزار شده و عزاداري ها هم انجام شده است.

 

مي خواهيد يک ايميل بفرستيد؟ مي توانيد از جي ميل استفاده کنيد. ولي اگر به هر دليلي خواستيد آن را به ليست غير قابل فهمي از افراد بي ربط و از طريق يک مسير بسيار غير طبيعي ارسال کنيد گوگل موج مي تواند کمکتان کند. آيا مي خواهيد آن ايميل را تبديل به يک آهنگ يا ويديو يا مکالمه اي درباره آهنگها و يا ويديو ها يي بکنيد که درون خودش آن آهنگ و يا ويديو را هم دارد؟ آيا مي خواهيد با شعبده بازي آدم هاي ديگر را وارد مکالمه بکنيد و يا از آن خارج کنيد جوري که خودتان هم نفهميد با کي داريد صحبت مي کنيد و آيا اصلا کسي حرفهايتان را دنبال مي کند يا نه؟ آيا دوست داريد هميشه امکان اين را داشته باشيد که در کنار مکالمه فعلي يک مکالمه ديگر راه بيندازيد و خودتان را در اين پارانوياي دايمي بيندازيد که بقيه دارند همزمان هم با شما حرف مي زنند و هم پشت سرتان حرف مي زنند؟

 

البته واضح است که گوگل موج اين قدرها هم بد نبود ولي مشکل آن همان مشکل اشتباه در پيش بيني نيازهاي کاربران بود. مساله اين است که حتي حرفه اي ها هم نمي توانند بگويند چرا گوگل موج اين قدر با بي مهري رو به رو شد. يکي از دلايل آن پيچيدگي زبان ارتباطي آن بود و از آن مهم تر ناتواني آن در برقراري ارتباط با ساير خدمات گوگل . برخي معتقدند گوگل موج هم دچار مشکل «جاي درست، زمان نادرست» شده و شايد در آينده موفقيت کسب کند.

 

 

 

منبع : بایت

http://www.yjc.ir/fa/news/4677178/%D8%AF%D9%87-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%B4%DA%A9%D8%B3%D8%AA-%D8%AE%D9%88%D8%B1%D8%AF%D9%87-google-%D8%B1%D8%A7-%D8%A8%D8%B4%D9%86%D8%A7%D8%B3%DB%8C%D8%AF

تصویر محمداسماعيل شركا
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط محمداسماعيل شركا - جمعه، 15 خرداد 1394، 08:54 ب.ظ
 
شکست چیست؟

ابتدا لازم می‌نماید که بدانیم شکست در یک پروژه به چه معناست. شکست در پروژه‌های نرم‌افزاری در هر یک از چهار مورد «هزینه»، «زمان»، «کیفیت» و «دست‌یابی به اهداف» مطرح می‌گردد؛ بدین معنا که اگر پروژه‌ای با صرف هزینه‌ی بیشتر یا زمان بیشتر یا با کیفیت پایین‌تر انجام گردد، علی‌رغم به پایان رسیدن پروژه، آن را توأم با شکست می‌دانیم.

1-2) 
آمــار
طبق آماری که نویسنده به دست آورده است تنها یک ششم پروژه‌های نرم‌افزاری تعریف شده (67/16%) در زمان معین و با هزینه‌ی پیش‌بینی شده به پایان رسیده استیک سوم پروژه‌ها (33/33%) فوراً متوقف گردیده و نیمه‌ی باقی‌مانده مورد بحث این مقاله است؛ که از این میان به طور متوسط پروژه‌ها با صرف 89/1 برابر بودجه (%189+) و 22/2 برابر زمان (%222+) انجام شده و تنها به 61/0 مشخصات تعریف شده دست یافته‌اند(61% اهداف).

بنابراین حساسیت این مطالعه و لزوم اتخاذ تدابیری جهت بهبود این وضعیت کاملاً مشهود است. لازم به ذکر است که آمار فوق تنها از یک جامعه‌ی آماری نمونه به دست آمده و ارقام و اعداد در دنیای واقعی قطعاً بیش از اینهاست، چرا که این مطالعه تنها بر مبنای پروژه‌های دفاعی نیروی هوایی ایالات متحده‌ی آمریکا انجام گردیده است.

مطالعات انجام شده مبین این نکته است که ریشه‌ی بیشتر علل شکست، در پیش از اولین خط کد نوشته شده یافته شده است، یعنی «طراحی». البته این موضوع را با شرح جزئیات بیشتر می‌توان کالبدشکافی نمود و جنبه‌های مختلفی را متذکر گردید که همگی در حیطه‌ی طراحی می‌گنجد.

3) 
علل اصلی شکست پروژه‌ها

بنا بر این مطالعه می‌توان موارد زیر را به عنوان «دلایل اصلی عدم توفیق در پروژه‌های نرم‌افزاری» ذکر نمود:
• 
ضعف ورودی کاربر
• 
نیازمندی‌های مبهم
• 
تخمین دور از واقعیت برای هزینه و زمان
• 
ناهماهنگی در مهارت‌ها
• 
هزینه‌های پنهان
• 
شکست طراحی
• 
طبقه‌بندی ارتباطات
• 
معماری ضعیف
• 
تأخیر در اعلان شکست
در بخش‌های بعد هر یک از موارد بالا را تشریح خواهیم کرد.

1-3) 
ضعف ورودی کاربر

هنگامی که مشاهده شود که سیستم به نیازهای کاربر پاسخ نمی‌دهد به چنین موردی بر می‌خوریم. این ضعف در سیستم از آنجا ناشی می‌شود که داده‌های اولیه در طراحی از ناظران سطح بالا اخذ گردیده است، که اینان به طور معمول از سیستم استفاده نمی‌کنند. در اینجا به گفته‌ی «پاول هیویت»، مشاور مرکز پشتیبانی فنی نرم‌افزار(STSC) ، اشارهمی‌کنیم:«پروژه‌ها با مشکل مواجه خواهند شد مگر اینکه کاربران آگاه طی هر فاز استخراج نیازمندی‌ها، طراحی محصول و ساخت، داده‌های ورودی با معنی به طراح بدهند. کاربر باید بپرسد: چگونه همه‌ی کارهایم را با سیستم انجام دهم؟ آیا سیستم ابزار درست و کارآمد را برای من تأمین می‌کند؟ باید چه چیز بهسیستم بدهم و در مقابل چه به دست خواهم آورد؟».
نکته‌ی دیگر در این باره را «شاری لاورنس فلیگر»، رییس شرکت نرم‌افزاری Systems در واشینگتن دی سی بیان می‌دارد:«... با وجود این کاربر نباید به بخش تعیین نیازمندی‌ها بیش از حد نزدیک شود. چون باعث بروز تداخل(Conflict) می‌گردد. کاربران درباره‌ی آنچه می‌خواهند و تبعات آن فکر نمی‌کنند، اینان تنها به این می‌اندیشند که کارها چگونه انجام می‌شده‌اند و در آینده چگونه انجام خواهد شد.».

2-3) 
ابهام در نیازمندی‌ها

بیانات «ماریا داتیز» رییس Peripheral Visions در هوستون تگزاس، درباره‌ی تجربیاتش در این خصوص مفید است:«کارفرما درباره‌ی آنچه که برنامه باید انجام بدهد ایده‌ای کلی دارد و در آن زمان که پروژه در دست مطالعه و طراحی است، ایده‌هایش را پالایش و اصلاح می‌کند. بنابراین در هر مرحله طراحان ناچار به عقب‌گرد می‌شوند ونتیجه آنکه هزینه‌ی پروژه و کیفیت به سرعت از کنترل خارج می‌شود، که البته نهایتاً شرکت ما مقصر شناخته می‌شود! بنابراین باید از ابتدا scope به حد کافی باریک و محدود باشد.

همچنین باید از ابتدایک خط پایه‌ی پایدار (permanent baseline) برای نیازمندی‌ها بنا نمود. هر چند که در هر صورت نیازمندی‌ها به طور خزنده تغییر می‌کنند.».
به هر حال در طی ساخت محصول نیازهای واقعی خودشان را نشان می‌دهند. اگر معماری و فرآیندها به طور هم‌گام با یکدیگر تغییر نکنند، پروژه به زحمت می‌افتد. نیز اگر خطوطراهنمای بنا شده نتوانند تعیین کنند که چه نیازمندی‌هایی افزوده یا حذف شوند، یا تغییر کنند و چه کسی مسؤول این تغییر و برعهده گیرنده‌ی هزینه‌هایمربوطه است، پروژه موفق نخواهد بود.

3-3) 
تخمین دور از واقعیت برای هزینه و زمان

پروژه‌های نرم‌افزاری همانند همه‌ی فعالیت‌های مهندسی دیگر، نیازمند تعیین حداقل هزینه و زمان هستند. یعنی یکنقطه‌ی مینیمم برای هزینه و زمان در هر پروژه وجود دارد که با مطالعه‌ی بیشتر روی آن حتماً مقدارش رشد خواهد داشت. «... اما خست به خرج دادن باعث طراحی‌های ضعیف، چگالی بالای عیوب، دوباره‌کاری و آزمون‌های بی‌پایانمی‌گردد. نهایتاً پروژه با پول و زمان بیشتر و کیفیت بدتر انجام خواهد شد.». این گفته‌ی «رابرت گزلتر» مشاور نرم‌افزار شرکت فلاشینگ در نیویورک می‌باشد.
«
کیپرز جونز» رییس مؤسسه‌ی تحقیقات بهره‌وری نرم‌افزار می‌گوید:«برای علاج این مشکل باید در تخمین هزینه و زمان پروژه از چند ابزار مختلف سود جُسته، پارامترهای عددی به دست آمده را ترکیب کرد تا به تخمینی واقعی‌تر دست یافت. حتی گاهی پیش از تعریف دقیق نیازمندی‌ها، برآورد لازم است.».

4-3) 
ناهماهنگی در مهارت‌ها

این مورد بیشتر در پروژه‌های دولتی مشهود بوده است و آن بدین خاطر است که در پروژه‌های دولتی قوه‌ی تصمیم‌گیری در دست اشخاصی است که خبره‌گی فنی ندارند.
پروژه‌هایی که به فناوری بالا متکی‌اند (High Tech) ، باید مدیرانی با مهارت‌های فنی بالا داشته باشند. اختیارات چنین طرح‌ها و پروژه‌هایی نیز باید در دست افرادی باشد که آگاهی فنی دارند و ریسک‌های فنی را می‌فهمند.
مجموعه‌ی مهارت‌ها برای مدیریت و برنامه‌نویسی از جدا می‌باشند. مدیریت پروژه‌های بزرگ نیاز به مهارت‌های عالی در «طرح‌ریزی»، «سازمان‌دهی»، «افق دید وسیع و عمیق» و «ارتباطات» دارد. استخدام افراد ماهر با حقوق بیشتر، از استخدام افرادی با حقوق کمتر که مدت‌ها طول می‌کشد تا صاحب تخصص شوند، به مراتب به‌صرفه‌تر است.
ماریا داتیز می‌گوید:«You get what you pay for! ، هر چه پول بدهی آش می‌خوری! اگر نمی‌توانی یهترینتکنسین‌ها(فنی‌ها) را استخدام کنی، بهترین مدیران را استخدام کن!».

5-3) 
هزینه‌های پنهان

ارزان تمام کردن، باعث بُروز هزینه‌های پنهان می‌شود. در تخمین هزینه و زمان باید متوجه هزینه‌های پنهان نیز بود. به عنوان مثال در نظر گرفتن تورم در تخمین هزینه‌ها مؤثر می‌باشد.

6-3) 
شکست طراحی

عدم طراحی جزئی و تعیین تکلیف برای افراد(به طور جزئی)، برای پروژه مشکل‌ساز می‌شود. برخی مدیران و پدیدآورندگان نرم‌افزار معتقدند به جای صرف وقت برای تعیین نیازمندی‌ها و طراحی و بررسی و... بهتر است به کار واقعی(کدنویسی و تست!) پرداخت، که سریع‌تر به نتیجه برسیم. اما مابین سرعت و پیشرفت تفاوت وجود دارد. در صورتی که طراحی مناسب باشد، هیچ نیازی به «قهرمان» نخواهد بود.

7-3) 
طبقه‌بندی ارتباطات

تیم‌های درگیر کار طراحی و کدنویسی باید با یکدیگر مراوده داشته باشند. چون حین انجام کار همواره مشکلات مشابهی پیش می‌آید، به خصوص اگر تیم‌ها در سایت‌های مختلف کار کنند؛ وجود مراوده و تبادل اطلاعات و مبادله‌ی تجربیات بسیار حائز اهمیت بوده، از صرف هزینه و وقت اضافی جلوگیری می‌کند.
برای انجام این امر باید فردی وجود داشته باشد که به کل کار محیط بوده و این هماهنگی‌ها را انجام دهد. در عین حال باید جلسات متعدد، متناوب و مستمر داشته باشیم تا هر کس بداند جزء کوچکی را که می‌سازد در کجای این پیکره‌ی عظیم قرار می‌گیرد.
ضمناً در طی این جلسات مشکلات هر تیم بیان شده و احیاناً اگر این مشکلات را حل کرده‌اند راه‌حل‌ها را نیز به اطلاع دیگران رسانیده و اگر در تیم دیگری چنین مشکلی بروز کند آنها راه حل را پیشاپیش خواهند دانست و ناچار به تجربه کردن تجربیات نخواهند بود.
نتیجتاً سرعت کار بیشتر شده و قطعاً هزینه نیز کاهش می‌یابد. هزینه‌ی مذکور شامل پول و زمان می‌باشد.

8-3) 
معماری ضعیف

در بحث «معماری ضعیف» تمرکز این مقاله بر روی انعطاف‌پذیری معماری می‌باشد. مثلاً نمونه‌ی تجربی موجود در جنگ خلیج دیده شده است. موشک «پاتریوت» برای مقابله با موشک«اسکاد» طراحی نشده بود ولی نرم‌افزار قادر به تغییر ساختار(برای پشتیبانی از عملکرد جدید) بود.
در سوی دیگر این طیف، برنامه‌های «حفاظت متون حساس» هستند که به سیستم عامل وابسته‌اند.
در طراحی نباید پروژه چنان طرح‌ریزی شده باشد که به ساختار ویژه یا سیستم عامل خاصی چنان وابسته باشدکه در پشتیبانی و به‌روزرسانی و افزودن بخش‌های جدید به سیستم دچار مشکل یا صرف هزینه‌ی گزاف شویم.
گزلتر در این باره می‌گوید:«نباید قایق بسیار زیبایی را در کارگاه ساخت که از در کارگاه بیرون نمی‌رود
ضمناً باید توجه داشت که: «اگر کارت را درست انجام دهی کسی نمی‌فهمد، ولی اگر اشتباه کنی ... !»
بنابراین در معماری و طراحی ساختاری سیستم، باید حداقل‌ها را در نظر گرفته، وابستگی سیستم بهplatformهای سخت‌افزاری و نرم‌افزاری را به حداقل رسانید.

9-3) 
تأخیر در اعلان شکست

مورد دیگر در شکست پروژه‌های نرم‌افزاری آن است که پس از مشاهده‌ی برخی عوامل مشکل‌زا، اگر در زمان مناسب تدابیر مؤثر اتخاذ نگردد برخی مسایل جبران ناپذیر خواهند شد. لذا باید در زمان لازم موارد خاص را کشف و حل نمود و هیچ‌گاه در اعلان آنها تأخیر نکرد. چرا که اگر موردی که در آینده مشکل‌ساز خواهد شد به موقع دیده نشده و رفع نگردد، شاید هرگز به رفع آن موفق نشویمضمناً مشکل مزبور ممکن است باعث بروز اشکالات دیگر نیز بشود.

نتیجه‌گیری

علاوه بر موارد مذکور، مشکلات و موانع بسیار دیگری نیز موجودند. به گفته‌ی جونز:«راه‌های شکست بسیارند، در حالی که تنها راه‌های اندکی برای موفقیت وجود دارند.».
اما با توجه به همین موارد معدود که شرح آن رفت، می‌توان تا حدود بسیار زیادی از بروز مشکلات جدی در هر پروژه بالاخص پروژه‌های نرم‌افزاری پیش‌گیری نمود.
من حیث‌المجموع در انجام هر نوع فعالیت مهندسی صرف زمان هنگام طراحی و بررسی کلیه‌ی جوانب کار بسیار به‌صرفه‌تر است از صرف هزینه‌های گزاف در فازهای بعدی پروژه، به منظور اصلاح مشکلاتی که اساساً می‌توانستپیش نیاید.

منبع: 

http://itpms.persianblog.ir/post/3/

تصویر سارا نوري
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط سارا نوري - جمعه، 15 خرداد 1394، 09:04 ب.ظ
  خلاصه مشخصات پروژه:
بخش فناوري اطلاعات يکي از شرکت هاي مشهور کشور به عنوان کارفرما با يکي از شرکت هاي ناموفق در زمینه تولید نرم افزار به عنوان پیمانکار، اقدام به انعقاد قراردادي براي طراحي و تولید "سیستم نرم افزاري مديريت اسناد و مدارک" نمود. 
براي طراحي و تولید اين نرم افزار هیچ مناقصه اي برگزار نشد و صرفا بدلیل ارتباطاتي اين پروژه مستقیما به پیمانکار سپرده شد.
(بدلیل سابقه همکاری چندين ساله با شرکت کارفرما از ذکر نام تجاري سیستم و نام شرکتها معذورم)
اين پروژه با آرمان به حداقل رساندن حجم کارهای اضافی با بهترین بهره وری از منابع انسانی و ساير منابع براي شرکت هاي پروژه محور تعريف گرديد.

اهداف پروژه:
هدف از طراحي سیستم مديريت اسناد و مدارك تهیه شده عبارت بود از :
- آسان سازي عملیات ذخیره و بازيابي کلیه مدارك تولید شده در شرکت
- ذخیره سازي متمركز فايلها براي ايجاد يك بستر اشتراكي به همراه ايجاد روشي استاندارد براي دسترسي به مدارك
- كنترل مدارك و بررسي نحوه دسترسي افراد مجاز به مدارك جهت بررسي روند ايجاد تغییرات و يا حذف و اضافه مدارك به صورت متمركز
- دسترسي سريع و آسان به مدارك پروژه هاي قبلي براي استفاده مجدد در پروژه هاي جديد
- آسان سازي عملیات و مديريت تهیه فايلهاي پشتیبان
- پاسخ گويي به تعداد تقاضاهاي زياد کاربران در ساختمان هاي متعدد شرکت کارفرما
- قابلیت انطباق و بهره گیری از ارتباطات شبکه کامپیوتري شرکت
- و در نهایت بازايابي براي فروش اين سیستم در سطح شرکت هاي عضو جامعه مهندسین مشاور ايران

نتیجه اجراي پروژه :
پیمانکار انتخاب شده اقدام به تحلیل و استخراج ناقص نیازمندي هاي سیستم نمود. متاسفانه هزینه های پروژه با بي دقتي تمام استخراج گرديد بطوري که در نهایت هزینه تمام شده بیش از هفت برابر هزینه پیش بیني شده بود. اجراي پروژه طبق برنامه زمان بندي جلو نرفت و پروژه تعريف شده براي 9 ماه، بیش از دو سال بطول انجامید. پس از تحويل سیستم و آموزش به کاربران، ايرادات عجیبي در سیستم بروز نمود و باعث وقفه در عملیات شرکت شد. شرکت پیمانکار يکي از برنامه نويسان خود را بصورت مقیم در شرکت کارفرما مستقر نمود و با هزینه بالاي دستمزد ساعتي فرد مزبور، ايرادات بسیار کند مرتفع مي شدند و در نهایت هر قسمت از سیستم با شکل و شمايل متفاوت و بسیار گسترده تهیه شد که نیاز به آموزش در سه جلسه چهار ساعته داشت. سیستم فاقد HELP بود و خطاها بسیار زياد و بصورت CODE ظاهر مي شد. متاسفانه تقاضاي کاربران بدلیل مشکلات و کاربر پسند نبودن سیستم تهیه شده، روز به روز بیشتر شد و در نهایت سیستم به سمت توقف و شکست کامل پیش رفت.

درس هاي گرفته شده از پروژه:
در انتها درس هايي که از اين پروژه نرم افزاري شکست خورده مي توان گرفت بشرح زير است:
- اهداف واقعي در نظر گرفته شوند.
- نیازمندي ها بدرستي استخراج شوند.
- مشخصات پروژه و تغییر نیازمندي ها بدرستي ديده شود.
- سیستم نرم افزاري سفارش داده شده در قالب تعاملي با سیستم هاي انساني بتواند به خوبي به اهداف در نظر گرفته شده پاسخ دهد.
- کیفیت نرم افزار سفارش داده شده از ديدگاه تناسب با هدف بدرستي اندازه گیري گردد.
- منابع مورد نیاز بدرستي تخمین زده شوند.
- سیاست هاي نگهداری مناسب اتخاذ گردد.
- از وضعیت پروژه گزارش درست گرفته شود.
- از فن آوري نرم افزاري ناكارآمد استفاده نشود.
- روش هاي توسعه بدرستي صورت پذيرد.
- ارتباطات قوي بین کلیه ذينفعان، شامل توسعه دهندگان و كاربران وجود داشته باشد.
- کلیه ذينفعان در پروژه درگیر شوند.
- پشتیاني قوي اجرايي میسر باشد.
- مديريت ريسک بدرستي انجام شود.
- مديريت قوي پروژه میسر باشد.
- سیستم هاي سفارشي، قابلیت بروز شدن با فناوري هاي روز نرم افزاري را داشته باشند.
- ناتواني فناوري مورد استفاده بدقت بررسي گردد.
- از تجربیات متخصصان و شرکت هاي مشابه استفاده گردد.
- پیش از طراحي نرم افزار، نرم افزارهاي آماده مشابه بررسي شوند.
- با توجه به استقرار مديريت کیفیت در شرکت، نظام مديريت کیفیت از سوي پیمانکار اجرا شود.
- فرايندهاي مهندسی نرم افزار بدرستي اجرا شوند.
- سیستم پیش از عملیاتي شدن، در شرايط واقعي تست شود.
- سیستم به عنوان يک مجموعه يکپارچه تست شود.
تصویر محمداسماعيل شركا
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط محمداسماعيل شركا - جمعه، 15 خرداد 1394، 09:11 ب.ظ
 
تاریخچه مدیریت پروژه‌های نرم افزاری با تاریخچه تولید نرم‌افزار در هم آمیخته‌است. نرم‌افزارها در آغاز برای مقاصد خاص و یا راه‌اندازی سخت افزارها نوشته می‌شد. اما با معرفی مفهوم برنامه‌نویسی شی‌گرا در سال ۱۹۶۰، برنامه نویسی با این رویکرد مورد استقبال شرکت‌های توسعه نرم افزار قرار گرفت و در دهه‌های ۱۹۷۰ و ۱۹۸۰ روند تولید و توسعه نرم افزار رشد سریعی را تجربه کرد.

در این زمان شرکت‌های تولیدکننده نرم‌افزار تلاش می‌کردند تا با استفاده از روش‌های کلاسیک مدیریتی، پروژه‌های نرم افزاری را راهبری کنند اما به زودی و با کند شدن سرعت تولید نرم افزار و بروز مشکلات جدی در تست و نیز تغییرات به وجود آمده در نیازمندی‌های مشتریان مشخص گردید که روش‌های سنتی مدیریت پروژه برای راهبری تیم‌های نرم افزاری مناسب نمی‌باشد. تحلیل و بررسی پروژه‌های نرم افزاری شکست خورده، عوامل زیر را به عنوان مهمترین دلایل شکست آن‌ها مشخص کرد:

  • عدم بیان روشن اهداف پروژه
  • برآورد نادرست از منابع مورد نیاز پروژه
  • تعریف نادرست نیازمندی‌ها
  • گزارش‌دهی ضعیف روند پروژه
  • استفاده از فناوری‌های نابالغ
  • عدم توانایی در کنترل پیچیدگی‌های پروژه
  • روش‌های توسعه غیر استاندارد
  • مدیریت پروژه ضعیف
  • سیاست‌های ذی‌نفعان
  • فشارهای مربوط به جنبه‌های تجاری پروژه

سه مورد نخست در فهرست بالا نشان می‌دهد که عدم بیان روشن و بدون ابهام نیازمندی‌های نرم‌افزاری توسط مشتریان منجر به اشتباه در هدف‌گذاری و تخصیص منابع مورد نیاز پروژه می‌شود.[۱]

 

منبع: http://fa.wikipedia.org/wiki/%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA_%D9%BE%D8%B1%D9%88%DA%98%D9%87_%D9%86%D8%B1%D9%85%E2%80%8C%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%DB%8C

تصویر كاظم گرشاسبي
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط كاظم گرشاسبي - جمعه، 15 خرداد 1394، 11:41 ب.ظ
  با سلام
موردی که بنده به تشریح آن پرداخته ام اتوماسیون داخلی یک سازمان نوپا می باشد
موردی که هیچ وقت در این مجموعه مورد اهمیت واقع نشد و حتی پس از شکست استقرار هم بی اهمیت ماند نیاز سنجی بود. در گام بعدی اینکه آیا یک اتوماسیون آماده که حتی قابل سفارشی سازی هست نیز می تواند نیاز این مجموعه را برطرف سازد یا نه. پس دو دلیلی که قبل از شروع باید به آنها پرداخته میشد در این مطالعه بررسی و تحلیل نشده بود. استقرار یک اتوماسیون اداری بسیار ساده، که می‌توانست کار را در سازمان تسهیل دهد از روی عدم شناخت امکانات آن و عدم تحلیل درست از فرایندهای سازمان باعث شد تا به شکست منجر شود. در این مورد از نظر زمان، هزینه، انتخاب پیمانکار هیچ مشکلی وجود نداشته است و فقط تحلیل غلط از فرایندها باعث شکست پروژه شده است.
محمد زند
پاسخ: مبحث مشارکتی: مطالعه موارد شکست در پروژه های نرم افزاری به دلیل ضعف نیازسنجی
توسط دستيار استاد - محمد زند - شنبه، 16 خرداد 1394، 07:12 ب.ظ
  عرض سلام و ادب و احترام 
خدمت تک تک دوستان 

اگر اجازه بدید بنده تمام این مبحث رو ملاحظه کنم
و امتیاز فعالیت ها رو ثبت کنم
بنا بر این خواهش می کنم از ساعت 24 روز 17 خرداد (بعد از امتحان) هیچ پستی رو اضافه نکنید

بسیار بسیار متشکرم

25 نظر

  • محمد زند / 10 شب / 5 دی 1395, / جواب

    ارسال آرشیو محتوا

    • محمد زند / 10 شب / 5 دی 1395, / جواب

      محتوای ارسالی از آرشیو 1393

به صفحه اول خوش آمدید